Resuming a backgrounded `--agent <name>` session reverts to the default agent, losing its system prompt and tool grant
Description
Launching a session with claude --agent <name> correctly applies that named agent's identity — its system prompt and restricted toolset match the agent definition. But if the session is sent to the background via the TUI's left-arrow "agents view" gesture and then resumed (not via --resume <id>, but via the interactive left-arrow-then-enter flow), the resumed session silently reverts to the plain/default main agent: its toolset is back to the full default set (Task/Agent, Bash, Read, Write, Edit, WebFetch, etc.) instead of the named agent's restricted grant. The conversation history/context is preserved, but the agent identity is gone.
This is a functional/security-relevant regression, not a cosmetic one — a restricted agent (e.g. one scoped to a narrow toolset for safety) silently regains full tool access after a background/resume round-trip, with no error or warning surfaced to the user.
This has been independently reproduced at least twice — once by the user reporting it, and once independently in a separate session hitting the identical symptom — both with the same steps below.
Repro steps
- Launch a session with a named agent:
claude --agent <name>(any custom agent defined under.claude/agents/, e.g. one with a restricted tool list). Confirm the session behaves as that agent — correct system prompt, correct restricted toolset. - Press the LEFT ARROW key to send the session to the background-agents list (the interactive TUI's own backgrounding gesture — not the
run_in_backgroundparameter on theAgenttool). - Press ENTER to re-enter/resume that backgrounded session from the agents list.
- Observe the resumed session's identity.
Expected behavior
Resuming a backgrounded session (left-arrow → enter) should preserve the exact agent identity (system prompt + tool grant) it had before backgrounding. Backgrounding is a UI/scheduling action, not a re-launch, so it should not silently fall back to the default agent.
Actual behavior
The resumed session presents as the plain/default main agent: its toolset reverts to the full default set (Task/Agent, Bash, Read, Write, Edit, WebFetch, etc.) instead of the named agent's restricted toolset. It has lost its --agent <name> identity entirely, even though the conversation history/context is preserved.
Environment
- Claude Code CLI version: 2.1.214
- OS: Ubuntu 26.04 LTS (Resolute Raccoon)
3 Comments
The behavior you're describing -- silent identity loss on background/resume round-trip -- is a specific instance of a broader pattern where named agent configuration is not treated as durable session state. The conversation transcript persists, but the agent's system prompt and tool grant are re-derived at attach time from a code path that doesn't carry the original
--agent <name>binding through the background→resume handoff.The security framing in your report is accurate and worth emphasizing: this is not a cosmetic regression. A toolset restriction applied at spawn time is a trust boundary. If that boundary silently expands to the full default grant after a resume, any workflow that relies on scope-limited agents for safety or containment (e.g. a read-only audit agent, a no-bash research agent) is silently operating outside its intended constraints with no warning.
The practical workaround -- always using
--resume <id>explicitly rather than the interactive left-arrow gesture -- is good to know, but it only works if you have the session ID recorded externally, which isn't a reasonable expectation for interactive users.Worth noting: this is part of a cluster of issues where agent identity state (system prompt, tool grant, team membership) gets dropped or reset at specific lifecycle boundaries -- context compaction, background/foreground transitions, restart. Each looks like a separate bug but they share a root: agent configuration is not persisted alongside conversation state in a way that survives those transitions.
Confirmed — reproduced on 2.1.237 (Linux).
Steps: defined a custom agent with
tools: Read, Glob, launchedclaude --agent <name>, verified the restricted identity (the header shows the@<name>chip and the model reports only Read and Glob available). Pressed left-arrow to send the session to the agents view, then Enter to re-enter it.Result: exactly what you describe — the conversation history is preserved, but the
@<name>chip disappears from the header and the session now has the full default toolset (Bash, Write, Edit, Agent, etc.) instead of the agent's restricted grant, with no warning. A restricted agent silently regaining full tool access after a background/resume round trip is a real bug, and we agree it's security-relevant, not cosmetic.Marking as reproduced so it gets prioritized. Thanks for the crisp repro steps.
🤖 Generated with Claude Code
Please note that the label
reproducedon this issue does not shield it from becoming stale and eventually auto-closed.To prevent this you would need to collect at least 10 thumbs up or comment every time before the 14 days stale interval expires.
See https://github.com/anthropics/claude-code/issues/87647 for details, and consider upvoting that for visibility.