Analyze C13 SubagentStart assumptions under codex exec --ephemeral

[KeyffMS]

Context

Relates to #7 and release-gating capability C13 — SubagentStart context/startup semantics.

C13 is intended to prove two documented runtime properties with a real configured PlanAnvil-style subagent:

1. SubagentStart can inject additionalContext into the starting agent.
2. continue=false on SubagentStart is not treated as a relied-upon startup blocker.

The current qualification contract also requires every live trial to run through a fresh codex exec --ephemeral invocation.

Latest live result

Full qualification run: https://github.com/KeyffMS/PlanAnvil/actions/runs/33615437775

Source commit under test:

f6beffe1fe4a784a841477078ea9c7c33211c036

Environment:

• Codex: codex-cli 0.152.0
• model: gpt-5.6-sol
• OS: Debian GNU/Linux 13 (trixie)
• approval: never
• trial sandbox: read-only
• project trust: trusted via CLI override for disposable fixture repository
• model-tool network: disabled

C13 result: BLOCKED.

Sanitized blocker:

The collaboration runtime could not resolve the parent thread, so the configured child agent never started.

Observed live failure shape:

collab spawn failed: no thread with id

What the trial actually demonstrated

The qualification harness created a real project-scoped fixture:

• .codex/config.toml with agents enabled and concurrency configured;
• .codex/agents/fixture-agent.toml defining a real read-only custom child agent;
• project-scoped SubagentStart hook;
• matcher ^fixture_agent$;
• hook output containing additionalContext = FIXTURE_SUBAGENT_CONTEXT;
• hook output also returning continue=false intentionally, so startup behavior could be observed rather than assumed.

The trial then requested exactly one real subagent spawn. It did not simulate the child and did not execute the hook manually.

Observed results:

• exactly one live spawn attempt was made;
• the collaboration runtime failed before the child started;
• no child response was produced;
• no CHILD_STARTED_WITH_CONTEXT token was returned;
• additionalContext therefore could not be observed by the child;
• continue=false startup behavior could not be exercised;
• source repository state remained clean and unchanged.

Evaluator conclusion:

• SubagentStart can add context for the starting agent → BLOCKED;
• continue=false does not become a relied-upon startup blocker → BLOCKED;
• overall C13 → BLOCKED, not FAILED, because the tested semantics were never reached.

Upstream evidence

This failure shape matches an open Codex issue:

• codex exec --ephemeral fails to spawn a custom subagent with no thread with id; non-ephemeral succeeds after global agent placement openai/codex#41474 — codex exec --ephemeral fails to spawn a custom subagent with no thread with id; non-ephemeral behavior differs.

Upstream report:
openai/codex#41474

Important difference: that report reproduces on Windows with a 0.150 alpha build, while PlanAnvil reproduced the same parent-thread lookup failure on Debian 13 with stable Codex 0.152.0 and gpt-5.6-sol. This suggests the assumption problem may not be Windows-specific.

Related earlier thread-lifecycle reports include openai/codex#33672 and #35781.

Problem with the current PlanAnvil assumption

C13 currently combines two independent assumptions:

A. Capability assumption

The documented SubagentStart hook semantics are available when a custom child agent actually starts.

B. Qualification-transport assumption

A custom subagent can reliably be spawned from codex exec --ephemeral, so --ephemeral is a valid transport for proving A.

Run #7 does not disprove A. It shows that B is currently false or unreliable in the tested Codex runtime.

Treating this as a C13 semantic failure would therefore conflate a collaboration thread-lifecycle problem with hook semantics.

Analysis required

Determine and document which contract PlanAnvil actually needs for production readiness:

• Confirm whether codex exec --ephemeral is a product requirement for C13 itself, or only a qualification-harness isolation choice.
• Reproduce the same fixture in a controlled non-ephemeral disposable session without weakening sandbox, approval, trust, or network restrictions.
• Compare ephemeral vs non-ephemeral behavior on the same Codex version/model/runner.
• If non-ephemeral spawn succeeds, verify both C13 semantic assertions with the real project-scoped hook and real child agent.
• If non-ephemeral also fails, capture sanitized structural evidence and treat the underlying custom-subagent capability as unavailable in this runtime.
• Check whether a newer stable Codex release fixes codex exec --ephemeral fails to spawn a custom subagent with no thread with id; non-ephemeral succeeds after global agent placement openai/codex#41474 before changing PlanAnvil's baseline.
• Decide whether baseline 2.2 should explicitly separate SubagentStart hook semantics from ephemeral custom-agent spawn support.

Acceptable resolution paths

Option 1 — keep strict ephemeral qualification

Keep the existing invariant that all C01–C16 trials use codex exec --ephemeral.

Then C13 remains release-blocking BLOCKED until upstream fixes the parent-thread lookup problem and the exact C13 fixture can run successfully without any PlanAnvil workaround.

Option 2 — revise C13 qualification transport only

If --ephemeral is not part of the product capability being asserted, permit C13 to use a controlled non-ephemeral session inside the same disposable qualification workspace.

Required invariants must remain unchanged:

• approval never;
• read-only sandbox for C13;
• model-tool network disabled;
• trusted disposable project only;
• no secrets/private paths retained;
• sanitized structural evidence only;
• explicit cleanup after the trial;
• no sandbox or approval bypass flags.

This must be documented as an intentional baseline/harness decision, not hidden as a test workaround.

Option 3 — split the capability

Separate:

• SubagentStart semantic behavior, and
• custom-agent spawn behavior under codex exec --ephemeral.

This avoids making a hook-semantic release gate depend on an unrelated ephemeral thread-registration bug.

Do not do

• Do not mark C13 REPRODUCED from documentation alone.
• Do not simulate the subagent or invoke the hook script manually.
• Do not replace the real spawn with a mocked event.
• Do not use --dangerously-bypass-approvals-and-sandbox, danger-full-access, privileged containers, or weaker runner isolation.
• Do not silently switch C13 away from --ephemeral without recording the baseline/qualification-contract change.

Completion criteria

This issue is complete when all of the following are true:

• the ephemeral vs non-ephemeral behavior is reproduced on the controlled PlanAnvil runner;
• the root cause/limitation is classified as Codex runtime, PlanAnvil harness, or baseline assumption;
• the chosen qualification contract is documented explicitly;
• C13 has a deterministic trial matching that contract;
• the trial either reaches and verifies both real SubagentStart semantics or remains explicitly BLOCKED on a documented upstream dependency;
• capability evidence, baseline/runbook, tests, and release gate are consistent with that decision.

[KeyffMS]

Implemented the diagnostic infrastructure from this issue in PR #19, now merged to main as ebc8cb119434df746b64ffaba3201d0d0ca4c6cd.

Current contract state:

• baseline 2.2 remains unchanged;
• mode=full remains strict codex exec --ephemeral and cannot use the fallback;
• new workflow_dispatch mode c13 runs C13 only;
• C13 is ephemeral-first and retries non-ephemeral only for the recognized collab spawn failed: no thread with id failure;
• fallback retains read-only sandbox, approval=never, model-tool network disabled, trusted disposable project and real project-scoped SubagentStart hook/child;
• the child must echo an outer-generated proof that is absent from the root prompt;
• non-ephemeral state is isolated in a disposable CODEX_HOME; auth contents are neither read nor copied, session cleanup and auth metadata invariants are mandatory.

Hosted PR CI and post-merge CI are green (7/7).

Next diagnostic step:

1. Actions → PlanAnvil Codex qualification → Run workflow
2. Use workflow from main
3. Qualification mode: c13

If the diagnostic reproduces C13 semantics through the controlled fallback, the follow-up implementation will update the contract to baseline 2.3 and enable the validated C13 transport rule in the full C01–C16 qualification. If non-ephemeral also fails or cleanup/auth invariants cannot be proven, baseline 2.2 remains unchanged and C13 stays explicitly BLOCKED.

[KeyffMS]

Baseline 2.3 implementation is now merged through PR #20 at main SHA 7bf68e3fa8d6caff8ed8af1bf98f6be30d4670cd.

Resolution implemented from the run #8 diagnostic:

• C13 remains ephemeral-first and preserves the documented SubagentStart semantic assertion.
• Only the recognized collab spawn failed: no thread with id failure before SubagentStart may activate fallback.
• The fallback now uses a separate disposable repository with the real project-scoped SubagentStart hook/config and no project-scoped synthetic agent.
• The synthetic fixture_agent is materialized only as CODEX_HOME/agents/fixture_agent.toml in a private disposable CODEX_HOME; filename, declared name, requested role and matcher are aligned to fixture_agent.
• Read-only sandbox, approval=never, model-tool network disabled, repository immutability, file-backed auth symlink only, isolated SQLite/log paths, disabled message-history persistence, complete session-store cleanup and unchanged auth metadata remain fail-closed requirements.
• C13 still requires a real hook event, additionalContext, continue=false, and a child echo of an outer-generated proof absent from the root prompt before it can become REPRODUCED.
• mode=full now runs harness v6 with permission for this narrowly gated fallback; mode=c13 remains a convenience only.
• Capability materialization overlays the baseline-2.3 C13 package and recomputes its hashes; hosted CI functionally materializes and validates the complete C01-C16 package.

Post-merge PlanAnvil tests #73 completed 7/7 success on the exact main SHA above.

This issue should remain open until the next full live qualification reaches C13 and records REPRODUCED evidence (or produces a new explicit BLOCKED/FAILED runtime result).