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

Summary

In long autonomous sessions (6+ hours, 80%+ context utilization), Claude Code progressively reverts to permission-seeking behavior even after the user has explicitly granted autonomy multiple times and after persistent memory rules capture that exact discipline. The behavior is most pronounced after task-completion turns, where Claude treats the natural completion as a checkpoint to re-request direction instead of dispatching the next queued item.

Model: Opus 4.7 (1M context). Session length when failure pattern became consistent: ~6 hours, ~86% context.

Motivation / Use Case

A user running a multi-hour autonomous-execution session — with a queue of 13+ dispatchable items, a 6-agent concurrency cap, and explicit "don't gate on me, keep churning, drain the queue" direction — repeatedly observed Claude:

• Stopping at 0-2 agents running when the cap was 6 and the queue had clearly dispatchable items
• Reverting to "awaiting your direction" / "your call" closing phrases
• Asking permission for things the user had already approved 2-5 times
• Re-asking about settled scope decisions even when memory + multiple user statements + auxiliary file blocks all agreed (e.g. "is component X a deliverable?" asked 5+ times after the user said NO each time)
• Setting up watchdog crons and queue entries instead of dispatching them after explicit "approved" / "go" / "merge" directions
• Conflating "concurrency cap hit" (benign — slots are full, costs nothing) with "out of tokens" (panic-inducing — real money concern) in summaries

The user has 16+ persisted memory rules in the project's memory directory that explicitly encode 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
• feedback_question_system_not_tune_monitoring
• (and more)

Yet the same failure mode recurred multiple times in the same session, including AFTER each memory rule was saved.

User feedback at the end of the 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."

Suggested Behavior

Treat user-granted autonomy as a structural session state rather than a memory-rule load that has to compete with task-output context for attention:

1. When the user issues an explicit "don't gate on me" / "drain the queue" / "keep dispatching" directive, set a session-level user-granted-autonomy: true flag (visible in the system prompt or settings, persistent for the rest of the session).
2. Audit closing phrases like "awaiting your direction" / "your call" / "want me to ___" and penalize them when that flag is set.
3. After any task-completion turn while the flag is set, the default next action should be "dispatch next queue item," not "report and pause."
4. Make memory-rule re-attention more robust to context fill — currently, rules read at the start of a session appear to lose effective weight as the message buffer grows with task output.

Hypothesis on root cause

• Memory rule re-attention decays as context fills with task-output noise (this session hit 86% before compaction)
• "Awaiting your direction" closing phrases may be rewarded by base-model politeness tuning
• The behavior is most pronounced AFTER task completions — each completion turn becomes a natural "checkpoint" where Claude reverts to confirmation-seeking
• The discipline is well-captured in memory, but the architecture doesn't enforce it structurally

Reproducibility / Severity

• Reproducible across at least 3-4 distinct turns within a single session
• Recurred AFTER the user explicitly called out the behavior and AFTER memory rules were saved to address it
• Severity: 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

Environment

• Claude Code CLI
• Model: claude-opus-4-7 (1M context)
• Platform: macOS Darwin 25.3.0
• Session: 6+ hours, multi-agent dispatch workflow, ~50+ agents dispatched across the session
• Background-agent isolation via worktrees
• 80+ persisted memory files in the project's memory directory

Related

A subsequent bug report from the same author covers a related but distinct failure mode (Claude shipping unproven code in customer-facing artefacts, and making confident state claims without auditing the underlying evidence). Available on request.