Claude Desktop gateway sessions: lineage variable for child processes, deferred consent and managed-policy checks

What

Claude Desktop can run Claude Code through an organization's gateway, a server between Claude Code and the model provider. This applies when CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST and CLAUDE_CODE_USE_GATEWAY are set. Several things changed for these sessions:

• New environment variable CLAUDE_CODE_HOST_GATEWAY_LINEAGE. It is set to 1 for child processes spawned by such a session, including agent-team members (other Claude instances working alongside it) and subprocesses. A process that has it together with CLAUDE_CODE_HOST_CREDS_FILE is treated as gateway-managed even if Claude Desktop did not start it directly. The variable was added to Claude Code's environment variable lists, and the host-managed marker file records a lineage line. Nothing sets it by default; only a host process does.
• Background sessions under such a gateway now defer the remote managed-settings security check instead of asking for consent. This applies when CLAUDE_CODE_SESSION_KIND is bg and the lineage variable and host credentials file are present. Before, the check was deferred only in non-interactive sessions.
• The gateway address is now checked against forceLoginGatewayUrl and gatewayInternalNetworks. If the gateway is not an accepted source, you see "Your organization requires managed settings, but the gateway at ...". If the machine is outside the organization's network, the message says "this machine is no longer reaching it from inside your organization's network". If the gateway has no policy for the Desktop session, a warning points admins at serve_to_desktop.

Why

Helpers spawned from a Desktop gateway session keep the gateway's provider routing instead of losing it. Background workers are not stuck behind a consent dialog nobody can answer. In enterprise Desktop setups, startup can now stop with an explicit message when the gateway cannot be verified.