{"version":"2.1.299","anchor":"self-hosted-runner-tools-host-in-session-token-response","canonical_anchor":"self-hosted-runner-tools-host-in-session-token-response","heading":"Self-hosted runners can be told to use a separate host for tools","tier":"notice","area":"Self-Hosted Runner","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299\/e\/self-hosted-runner-tools-host-in-session-token-response","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299","markdown":"### Self-hosted runners can be told to use a separate host for tools\n\nOn self-hosted runners, the session token answer can name a tools host, which skips the remote setup fetch and keeps the token out of the environment\n\n**Unclear.** It is not stated when the server includes a tools host in its answer.\n\n**What**\n\nA self-hosted runner is a machine you run yourself to carry out remote Claude Code sessions. When the runner asks the server for a session token, the answer may now also describe a tools host: where the session's tools are served from, an address for API calls and a working folder. When it does:\n\n- The runner skips fetching the usual `\/remote` setup and uses a setup built from that answer.\n\n- The session token is not set as `CLAUDE_CODE_SESSION_ACCESS_TOKEN`.\n\n- The session keeps its tool-server settings in a separate folder.\n\n- If the tools host description cannot be read, the runner stops with an error saying the answer holds a tools host it cannot read.\n\n**Why**\n\nThis prepares for sessions whose tools run in a separate hosted container. Scripts that rely on `CLAUDE_CODE_SESSION_ACCESS_TOKEN` will not find it in such sessions.\n\n- Area: Self-Hosted Runner\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 4\/5\n- Scope: org\n- Heads-up: no"}