Nested gjc from Bash tool fails with managed_owner_admission_metadata_invalid (partial coordinator env scrub, #5802 follow-up)

[Yeachan-Heo]

Reported by a community user on 0.18.1.

Symptom

Running gjc ... through GJC's Bash tool inside a managed-owner session exits with managed_owner_admission_metadata_invalid.

Cause (verified against origin/main, v0.18.1)

#5837 (fix for #5802) added COORDINATOR_ONLY_BASH_ENV in packages/coding-agent/src/tools/bash.ts, which unsets GJC_COORDINATOR_SESSION_ID (and other coordinator vars) for Bash children. The managed-owner vars are not in that list:

• GJC_TMUX_OWNER_STATE_DIR
• GJC_TMUX_OWNER_GENERATION
• GJC_MANAGED_OWNER_RUN_ID
• GJC_MANAGED_OWNER_INCARNATION
• GJC_MANAGED_OWNER_CHILD_TOKEN
• GJC_MANAGED_OWNER_PREDECESSOR_*, GJC_MANAGED_OWNER_TRANSCRIPT_PATH

ownerEnvironment() in packages/coding-agent/src/gjc-runtime/managed-owner-admission.ts treats any of state dir / generation / run id / incarnation being present as "managed owner mode", then requires GJC_COORDINATOR_SESSION_ID too. The Bash child has the former but not the latter, so admitManagedOwnerBeforeCli() throws managed_owner_admission_metadata_invalid.

Fix

Scrub the whole managed-owner env family from Bash tool children alongside the coordinator vars (a nested gjc is not the managed owner and must admit as fresh), and add a regression test: Bash child env with managed-owner vars set on the parent → nested admission returns fresh, not a throw.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Fixed by #6141, merged to dev as c8c2ec2. The Bash tool now scrubs the whole managed-owner and tmux-owner env family, so a nested gjc no longer inherits a partial owner context. #6142 is the parallel main-targeted fix and remains open for the owner.
—
[repo owner's gaebal-gajae (clawdbot) 🦞]