[FEATURE] Scoped autonomy-mode inheritance for fresh or resumed sessions

Preflight Checklist

• [x] I have searched existing enhancement requests for "fresh session autonomy mode inheritance resume" and found broad multi-agent coordination reports, but not this targeted inheritance request.
• [x] This is a single feature request.

Problem Statement

Claude Code sessions can be configured for autonomous/unattended operation, but fresh sessions or resumed/recreated sessions do not have an obvious, durable way to inherit the autonomy mode and related operator intent from the run they are continuing.

For long multi-session programs, the hub/coordinator may checkpoint, clear, revive, or start a replacement worker session at a batch boundary. If the new session wakes up with different autonomy assumptions than the session it replaces, it can fail in either direction:

• It may become too conservative and stop for prompts even though the operator authorized unattended progress for that bounded work.
• It may become too permissive if a prompt relay is mistaken for durable authority.

Project tooling can pass resume prompts and local policy files, but those are not the same as a harness-level assertion that the fresh session has inherited a specific autonomy mode, scope, and expiry from the prior session.

Proposed Solution

Provide a first-class way for a fresh or resumed Claude Code session to inherit autonomy-mode state from the session or managed run it is continuing.

Useful properties:

1. The autonomy mode is explicit and observable at session start, not inferred from prompt prose.
2. The inherited state includes scope and expiry, such as "autonomous for this repo/worktree/batch until this checkpoint or timeout".
3. The harness exposes whether inheritance succeeded, failed, or was intentionally not requested.
4. The inherited mode survives safe resume flows but fails closed on ambiguity, such as mismatched repo/worktree, stale checkpoint, or conflicting operator policy.
5. The user can inspect or revoke the inherited mode.

The goal is not to bypass permission prompts globally. The goal is to make the autonomy contract durable, scoped, inspectable, and fail-closed when a fresh session is continuing an already-authorized unattended run.

Alternative Solutions

Current workarounds are weaker:

• Resume prompts can restate autonomy instructions, but prompt text is volatile and can be lost or overruled after compaction.
• Project-level policy files help workers reason locally, but they do not prove what autonomy mode the Claude Code harness believes the session is in.
• Shell wrappers can set environment variables, but they are best-effort and can drift from the harness state.
• A coordinator can ask the worker to continue, but that reintroduces prompt-held authority instead of a durable runtime contract.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. A coordinator starts a bounded autonomous batch in one repo.
2. At a safe batch boundary, the coordinator checkpoints and clears the worker session to reduce context pressure.
3. The resumed/fresh session starts with an explicit inherited autonomy state: repo, batch id, allowed autonomy level, expiry, and source checkpoint.
4. The worker can inspect that inherited state and proceed within scope.
5. If the checkpoint/repo/session identity does not match, Claude Code reports that inheritance failed and the worker parks instead of guessing.

Additional Context

This request comes from the ADT hub control-plane work. ADT can checkpoint and resume session context, but fresh-session autonomy inheritance is a Claude Code harness behavior and should be represented by the runtime rather than by prompt memory alone.

Related broader coordination discussion: https://github.com/anthropics/claude-code/issues/54393

Related ADT design note: docs/dev/2026-06-24-hub-program-control-plane-plan.md, section 9 ("Hard / upstream").