claude-code - 💡(How to fix) Fix [DOCS] `/bg` preservation of MCP/settings/add-dir/plugin flags across respawn is undocumented

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://code.claude.com/docs/en/agent-view

Section/Topic

From inside a session, Settings, plugins, and MCP servers, and the background-session respawn lifecycle

Current Documentation

The docs currently say:

Run /background or its alias /bg to move the current conversation into a background session. Pass a prompt such as /bg run the test suite and fix any failures to give one more instruction first.

Backgrounding from an interactive session starts a fresh process that resumes from the saved conversation, so running subagents, monitors, and background commands do not transfer to it.

Later on the same page they say:

Agent view accepts the same configuration flags as claude for loading settings, plugins, MCP servers, and additional directories. Each flag applies to agent view itself and is passed through to every session you dispatch from it, so a plugin or MCP server you load this way is available in those sessions too.

--settings <file-or-json> --add-dir <path> --plugin-dir <path> --mcp-config <file-or-json> --strict-mcp-config

The lifecycle section also says:

Once a session finishes and sits unattached for about an hour, the supervisor stops its process to free resources. The transcript and state stay on disk, and the next time you attach, peek, or reply, the supervisor starts a fresh process from where it left off.

What's Wrong or Missing?

Changelog v2.1.143 says:

/bg now preserves --mcp-config, --settings, --add-dir, --plugin-dir, and --strict-mcp-config, so backgrounded sessions keep their MCP servers and settings across respawn.

The current agent-view page documents three related pieces separately:

1. /bg starts a fresh background process.
2. claude agents passes configuration flags through to sessions dispatched from agent view.
3. Finished background sessions are later restarted from saved state.

What it does not say is that these same session-scoped configuration flags are preserved when you background an already-running session with /bg, and that they remain in effect when the background session is respawned later.

That leaves a concrete documentation gap for MCP- and config-dependent workflows. A reader cannot tell from the current page whether a session started with custom MCP servers, settings overrides, added directories, plugin directories, or --strict-mcp-config will keep those inputs after /bg forks the session and the supervisor later restarts it.

Suggested Improvement

Add a short note to agent-view near the /bg and session-lifecycle documentation stating that backgrounding an interactive session preserves these session-level startup flags across later respawns.

Suggested wording:

If the current session was started with --mcp-config, --settings, --add-dir, --plugin-dir, or --strict-mcp-config, running /bg carries those settings into the forked background session. They stay in effect if the session is later restarted from saved state.

This would make it clear that /bg preserves the same MCP servers, settings overrides, added directories, plugin directories, and strict MCP behavior after idle retirement or any other respawn described on the page.

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:

Total scope: 1 page affected

Source: Changelog v2.1.143

Changelog entry: /bg now preserves --mcp-config, --settings, --add-dir, --plugin-dir, and --strict-mcp-config, so backgrounded sessions keep their MCP servers and settings across respawn.