A vitals-emitter-guest child process is built in pinned mode, so nothing resolves outside hosted cloud workers.
Sessions running on Anthropic's hosted cloud workers can launch an external helper called vitals-emitter-guest as a child process that reports session health back to the service. It only starts when there is an SDK URL, a remote session id and a readable session token file, so anyone running the CLI locally never sees it. The cloud session launcher builds the emitter in pinned mode, and in that mode the path resolver will not search PATH, so on a normal install nothing resolves and nothing spawns.
- The child is invoked with
--session-id,--api-urland--token-file. - The binary path comes from the
VITALS_EMITTER_BINenvironment variable, which must be absolute, otherwise a PATH lookup, otherwise a fallback of/root/.local/bin/vitals-emitter-guest; pinned mode skips the PATH lookup entirely, so with no absoluteVITALS_EMITTER_BINthe emitter resolves to nothing and stays off. - Setting
CLAUDE_CODE_DISABLE_VITALS_EMITTERturns it off, and essential-traffic-only mode bails out of it too. - The child runs with a scrubbed environment holding only PATH, HOME, TMPDIR, the proxy variables and SSL_CERT_FILE.
- The process is supervised: respawned with backoff, stopped with SIGTERM then SIGKILL, and its stderr is piped into the log.
- Telemetry under the name
ccr_vitals_emitterrecords success, spawn_failed and exited_unexpectedly. - None of this machinery is present in 2.1.238.
[vitals] kill switch or essential-traffic-only set; guest vitals disabled, [vitals] VITALS_EMITTER_BIN not set; guest vitals disabled (this launcher does not search PATH)
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
New in this build: CLAUDE_CODE_DISABLE_VITALS_EMITTER