claude --bg sessions inherit the daemon's environment (first terminal), not the calling shell's

Summary

claude --bg gives the new session the environment of the running claude daemon, not the environment of the shell that ran claude --bg. The daemon keeps the environment of whichever terminal started it first, for as long as it lives (more than ten hours here). So every later background session, started from any terminal, carries that first terminal's variables.

It matters when those variables identify the terminal. Terminal apps export per-pane identity variables. Orca, for example, sets ORCA_PANE_KEY, ORCA_TAB_ID and ORCA_AGENT_HOOK_*. A background session started from pane B then carries pane A's identity, and anything that keys on those variables attributes it to pane A.

Environment

Claude Code 2.1.287, macOS 26 (Darwin 25.5.0).

Evidence

Variable names only, read with ps eww -p <pid>:

• The claude daemon run --origin transient process holds 15 ORCA_* names, among them ORCA_PANE_KEY, ORCA_TAB_ID, ORCA_WORKTREE_ID and ORCA_AGENT_HOOK_ENDPOINT.
• A --bg-spare process the daemon started 32 seconds before the read, before any claude --bg call could shape it, carries the same ORCA_PANE_KEY, ORCA_TAB_ID and ORCA_TERMINAL_HANDLE as the daemon.
• A session started with claude --bg from a different shell has an ORCA_PANE_KEY equal to the daemon's.

Repro

1. In terminal A, export FOO_IDENTITY=a, then start the daemon, for example with a first claude --bg "hi".
2. In terminal B, export FOO_IDENTITY=b, BAR_MARKER=1, and an empty BAZ=, then run claude --bg "print env".
3. In the new session, FOO_IDENTITY is a, BAR_MARKER is absent, and an empty value set in B does not override A's.

Nothing in the calling shell's environment reaches the session. Unsetting, blanking or overriding a variable before claude --bg has no effect.

Expected

A background session gets the environment of the shell that ran claude --bg. At the least, it does not get another terminal's variables: the daemon could drop variables the caller did not have, or let the caller's values override its own.

Workaround

Restart the daemon from a shell without such variables. That holds until a terminal with them starts the daemon again.