{"version":"2.1.310","anchor":"self-hosted-runner-reports-capabilities-and-adds-a-header-to","canonical_anchor":"self-hosted-runner-reports-capabilities-and-adds-a-header-to","heading":"Self-hosted runners now report their capabilities","tier":"internal","area":"Self-Hosted Runners","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310\/e\/self-hosted-runner-reports-capabilities-and-adds-a-header-to","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310","markdown":"### Self-hosted runners now report their capabilities\n\nSelf-hosted runners now send a capabilities list when they register and a capabilities header when fetching session settings; the orchestrator client sends an empty list\n\n**What**\n\nA self-hosted runner is a machine you run yourself to carry out remote Claude Code sessions. Runners now tell the server what they support.\n\n- When a runner registers, its request now includes `capabilities`.\n\n- When it fetches a session's remote settings, it sends an `x-self-hosted-runner-capabilities` header, a small label attached to the request.\n\n- The runner orchestrator client is created with `capabilities: []`, an empty list.\n\n**Why**\n\nThis is a new field in how runners talk to the server. For now, the orchestrator client reports no capabilities.\n\n- Area: Self-Hosted Runners\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5\n- Scope: org\n- Heads-up: no"}