Skip to content

fix(codex): recognize collaboration subagent lifecycle in dispatch guard #168

Description

@Orinks

Problem

The Codex dispatch guard blocks valid UI edits even after accessibility-lead and required specialists complete when the session exposes Codex collaboration agents instead of multi_agent_v1 custom subagents.

The collaboration spawn/wait path completes successfully, but it does not emit the SubagentStart/SubagentStop hook payloads expected by a11y-codex-dispatch-guard.mjs. As a result, PreToolUse continues to report that accessibility-lead was never spawned, and Stop reports every review missing.

In the affected desktop session, tool_search and multi_agent_v1.spawn_agent were not exposed; collaboration.spawn_agent was the only subagent path.

Reproduction

  1. Start a Codex desktop task that triggers the web-accessibility guard.
  2. Spawn accessibility-lead, aria-specialist, and keyboard-navigator through collaboration.spawn_agent.
  3. Wait for all agents and obtain their final results.
  4. Attempt apply_patch on a TSX file.
  5. The guard denies the edit because no lifecycle marker exists.

Confirmed workaround

Forwarding equivalent SubagentStart/SubagentStop JSON payloads to the guard after each collaboration agent completes creates the expected markers and immediately allows the guarded edit. This confirms the review itself is complete and marker transport is the missing layer.

Suggested fix

Provide a supported collaboration-agent receipt/bridge path, or teach the guard/installer to consume the lifecycle events emitted by the current Codex collaboration tool. Add a smoke test that exercises the actual available subagent surface rather than only checking source phrases.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions