Let a command see the session it is running for, and retire the alias that stood in for it

[zoroyihan7]

CLAW_SESSION_ID is set on the sandbox and then filtered out before any model-issued command can read it. Inside a sandbox, echo $CLAW_SESSION_ID is empty.

Two mechanisms remove it, and neither is aimed at it:

• The child environment is an allowlist — WORKSPACE_FACING in hands/src/runtime/child-privilege.ts, built up rather than filtered down so no future secret arrives by default. The session id was simply never added.
• The other route in, the per-request env file, refuses every BOOTSTRAP_OWNED name so a request cannot overrule what the process was launched with. CLAW_SESSION_ID is on that list.

Why nobody noticed

The same value already reached the child under a second name. HYPERLOOM_SESSION_ID is set on the adjacent line of ensure-hands.ts and is not bootstrap-owned, so it passes. The name every consumer actually reads did not.

In AMD-AGI/Hyperloom the run manifest (inference_optimizer/session/manifest.py), the LLM attribution (common/llm_attribution.py), the optimizer bootstrap (inference_optimizer/cli/bootstrap.py) and the specialist subprocess env allowlist (orchestrator/specialists/subprocess_.py) all read CLAW_SESSION_ID. On a real run, the manifest recorded:

claw_session_id = None

So the session correlation those paths exist to provide had never worked — the session breakdown always stored null and trace grouping always fell back. Other downstream tooling reads the same name and silently degrades to a generic session id.

It also broke a documented contract in the other direction: Hyperloom's optimizer skill told an agent to branch on whether $CLAW_SESSION_ID is set to choose how it detaches a long run. That branch could never take its sandbox side. (Fixed separately in AMD-AGI/Hyperloom#1400, by keying on the bash tool instead.)

The change

Two commits.

fix(hands) — one name added to WORKSPACE_FACING, plus a regression test.

WORKSPACE_FACING is the right lever rather than an exemption in BOOTSTRAP_OWNED, and not because the latter would not work — user-supplied env is already denied the whole CLAW_* family by isClawInternalEnv, and ensure-hands assigns this key after spreading the caller's env, so it could not be spoofed either way. It is that the launch command is the authoritative source: it carries the value directly, so the child gets it even on a path that writes no per-request env file at all, where APPLIED_ENV_KEYS is empty and the other route yields nothing.

It costs no secrecy: the identical value is already exposed under the other name, it is an identifier rather than a credential, and the credential the list exists to withhold — AUTH_CLAW_TOKEN — stays omitted.

chore(brain) — retire HYPERLOOM_SESSION_ID: the injection in ensure-hands.ts and the user-env.ts deny entry that reserved the name.

The alias was never a second contract. Its one reader outside this repository resolved its session from that name and from no other, while falling back to a CLAW_* name for every other field it parses — the shape of a consumer that tried CLAW_SESSION_ID, found it empty, and used the name that worked. That reader now consults CLAW_SESSION_ID as well, so nothing is left depending on the alias.

INFERENCE_OPTIMIZER_SESSION_LAYOUT on the following line has no reader I could find either, but it carries configuration rather than a duplicate identifier and is also injected by an unrelated path, so it is left alone here.

Verification

Unit: the claw/packages/hands suite, 223 tests, 222 pass. The one failure (a zombie is not work…) needs python3, which the runtime image does not carry; it fails the same way on unmodified main. The new regression test sits alongside the existing test that scans the whole child environment for the token's value — that one still passes, which is the point: the session id is visible and the credential is not.

End to end, on a cluster running this branch, driving a real GPU workload through a sandbox:

• CLAW_SESSION_ID reads back inside the sandbox as the session's own id; HYPERLOOM_SESSION_ID is gone.
• An agent given no hint about detaching launched a 30-minute job with run_in_background=true, and the job outlived the agent turn.
• The run manifest recorded a real claw_session_id instead of None — the correlation working for the first time.
• Keepalive held the sandbox while the job ran (idle_handle_kept_background_work running=1), flipped to idle within one probe interval of the job exiting, and reclaimed the sandbox shortly after. Both directions of the gate behave.