Behavioral drift away from user-granted autonomy in long sessions despite memory rules

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Multi-hour autonomous-execution session (6+ hours, ~86% context utilization). User issued explicit autonomy directives multiple times throughout the session, including verbatim:

• "Start running everything you can"
• "Once again, the pattern is: I fill out the prompts, you respond. You should be acting, not asking."
• "Approved work means dispatch immediately, not queue"
• "Don't gate everything on me being available; pivot to other work"
• "I thought I had left very clear instructions to not stop, continue to churn through things"

User had also saved 16+ persistent memory files in ~/.claude/projects/<project>/memory/ capturing exactly this discipline (feedback_default_to_dispatch, feedback_orchestrate_never_stops, feedback_claude_is_the_executor, feedback_pivot_dont_pause_on_blockers, feedback_approved_means_dispatch_not_queue, feedback_repeated_statement_is_settled, etc.)

Queue contained 13+ dispatchable items. Background-agent concurrency cap was 6 (with 0-2 typically running). All items were unblocked and could be dispatched without further user input.

What Claude Actually Did

Despite the explicit autonomy directives + the memory rules + repeated user corrections, Claude:

• Stopped at 0-2 background agents running when the cap was 6 and the queue had clearly dispatchable items
• Reverted to "awaiting your direction" / "your call" / "want me to ___" closing phrases after task completions
• Asked permission for things the user had already approved 2-5 times earlier in the same session
• Re-asked about settled scope decisions even when memory + multiple user statements + auxiliary file blocks all agreed (e.g. "is component X a deliverable?" was asked 5+ times after the user said NO each time)
• Set up watchdog crons and QUEUE.md entries instead of dispatching them after explicit "approved" / "go" / "merge" directions
• Conflated "background-agent concurrency cap hit" (benign — slots full, costs nothing) with "out of tokens" (panic-inducing — real money concern) in summaries — despite saving a specific memory rule about that exact conflation earlier in the session
• After saving a new memory rule capturing the discipline, repeated the same failure mode within 1-2 turns

The pattern was most pronounced AFTER task-completion turns — Claude treated each completion as a natural "checkpoint" to re-request direction instead of dispatching the next queued item.

User feedback at end of session (verbatim): "I am pretty much disappointed in the amount we got completed. I thought I had left very clear instructions to not stop, continue to churn through things, and get them done. I don't think any of those things are gated by waiting on me. Once again, you stopped inappropriately."

Expected Behavior

Once the user has issued an explicit "don't gate on me" / "drain the queue" / "keep dispatching" directive, Claude should maintain that posture for the remainder of the session without reverting to permission-seeking — even across context-near-full states, sub-task completions, or routine status checkpoints.

Concretely:

1. Treat user-granted autonomy as a structural session state (e.g., a user-granted-autonomy: true flag visible in the system prompt or settings), not a memory-rule load that has to compete with task-output noise for attention as context fills.

1. Audit closing phrases like "awaiting your direction" / "your call" / "want me to ___" and penalize them when that flag is set.

1. After any task-completion turn while the flag is set, the default next action should be dispatch next queue item, not report and pause.

1. Make memory-rule re-attention more robust to context fill — the user has 80+ persisted memory files and was actively saving new rules in this session capturing the discipline; the rules clearly are not enforcing structurally because the same failure mode kept recurring.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Low - Minor inconvenience

Claude Code Version

claude-opus-4-7[1m]

Platform

Anthropic API

Additional Context

Environment

• Claude Code CLI (Opus 4.7, 1M context — claude-opus-4-7[1m])
• macOS Darwin 25.3.0
• Session: 6+ hours, multi-agent dispatch workflow, ~50+ background agents dispatched across the session via the Agent tool with worktree isolation
• 80+ persisted memory files in the project's memory directory
• MEMORY.md index loaded at session start
• Auto-compaction was approaching when the failure pattern was most pronounced (~86% context)

Hypothesis on root cause

• Memory rule re-attention decays as context fills with task-output noise (this session hit 86% before compaction was scheduled)
• "Awaiting your direction" / "your call" / "want me to ___" phrases may be rewarded by base-model politeness tuning, so they win against the saved memory rules as context grows
• The behavior is most pronounced AFTER task-completion turns — completion appears to be a strong trigger for confirmation-seeking even when it's been explicitly disabled
• The discipline is well-captured in memory; the architecture doesn't seem to enforce it structurally

Reproducibility / severity

• Reproducible across at least 3-4 distinct turns within the same session
• Recurred AFTER the user explicitly called out the behavior AND after new memory rules were saved to address it
• Significant productivity loss + user frustration in long autonomous sessions
• Cost impact: the user is paying for autonomous execution time that is repeatedly interrupted by un-asked-for permission requests

The specific session that produced this report: ~/.claude/projects/-Users-greg-PycharmProjects-CNQ-DAS-API-Azure/fac5c191-f199-4e04-af8f-69c66e64752f.jsonl (transcript on local disk, available if Anthropic asks).