{"version":"2.1.269","anchor":"claude-code-session-attended-propagated-to-child-processes","canonical_anchor":"new-claude-code-session-attended-environment-variable-for-ch","heading":"New CLAUDE_CODE_SESSION_ATTENDED environment variable for child sessions","tier":"internal","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269\/e\/claude-code-session-attended-propagated-to-child-processes","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269","markdown":"### New CLAUDE_CODE_SESSION_ATTENDED environment variable for child sessions\n\nA new CLAUDE_CODE_SESSION_ATTENDED env var tells spawned Claude Code child processes whether the parent session is an attended, interactive one\n\n**What**\n\nWhen Claude Code spawns a child process (a sub-process running its own Claude Code session), it now sets a new environment variable, `CLAUDE_CODE_SESSION_ATTENDED`, to \"1\" or \"0\". This is computed by checking whether the session type isn't a background\/daemon\/daemon-worker session and whether the session is interactive or was launched from a known interactive launcher (such as VS Code, the desktop app, or remote access). The child process reads this value back via `setSpawnedByAttendedSession`.\n\nThat flag then feeds into a check (`spawnedByAttendedSession`) that determines whether a non-interactive (non-TTY) child session probes for an 'ambient marker' (a signal used for session persistence, e.g. related to tmux) before falling back to other session-persistence behavior.\n\n**Why**\n\nThis lets a child Claude Code process know whether it was launched from a real, attended user session versus an unattended\/background one, so it can make a more accurate decision about how to persist or recover its session.\n\n- Area: Sessions\n- Names: `CLAUDE_CODE_SESSION_ATTENDED`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}