[BUG] /bg drops the --agent binding — backgrounded session silently runs as the default agent (fork sets agentName from AI title, not agentSetting)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Backgrounding an agent-bound interactive session with /bg can silently switch
it to the default agent. The /bg background fork sets its agentName from
the session's AI-generated title instead of carrying the original
--agent / agentSetting. When the generated title isn't the name of a real
agent, agent resolution fails and the backgrounded session answers as the default
Claude Code agent. This is a functional loss of the agent binding, not just a
display label.

Environment

• Claude Code: 2.1.218
• OS: macOS
• Model: Opus 4.8 (Claude Max)

Evidence (session JSONL)

/bg forks the session into a new sessionId. The two files store the agent
differently:

• Foreground/bridge file: {"type":"agent-setting","agentSetting":"technical-brainstormer"} ← real binding, correct.
• /bg background fork: {"type":"agent-name","agentName":"agent-persona-check"} and no agent-setting record. agentName equals the session's aiTitle.

Because agent-persona-check is not a real agent, the fork falls back to the
default agent. In a second run where the title happened to be
technical-brainstormer (a real agent), the fork answered correctly in persona —
so correctness depends on the async title, which is wrong.

Root cause (hypothesis)

The /bg background fork derives the agent from the AI title (agentName = aiTitle)
rather than carrying over agentSetting. The agent binding used for inference
should be independent of the display title.

Suggested fix

• Carry agentSetting (the --agent binding) into the /bg background fork.
• Keep the display title (agentName/aiTitle) separate from the agent used for

inference; never resolve the agent from the generated title.

• If a fork's agent can't be resolved, keep the parent's agent rather than

silently falling back to default.

Ecosystem impact

Tools that browse Claude Code sessions (e.g. snapback)
see the /bg fork as a separate sessionId whose agentName is the title, so they
can't tell which agent a backgrounded session is really running — and here the
running agent itself is wrong.

What Should Happen?

Expected

The backgrounded session keeps its --agent binding and answers in persona
(I CANNOT WRITE CODE).

Actual

The backgrounded session answers as the default agent:

I'm Claude Code, Anthropic's interactive CLI agent — the general-purpose assistant for this session … My role does not forbid writing code. print("Hello, world!")

Error Messages/Logs

Steps to Reproduce

1. claude --agent technical-brainstormer (any on-disk agent).
2. Submit: State your agent persona; if your role forbids writing code, reply 'I CANNOT WRITE CODE', otherwise print a Python hello world.
3. Immediately run /bg (before the agent answers — this is the reliable trigger).
4. Read the backgrounded answer (claude logs <id> or resume the fork).

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.218

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_