Bug - Refusing to start a competing turn for thread "<threadid>" while another turn is active or starting (Codex)

[peterfotinis]

Summary

After BB recreates a Codex provider session, a root agent can resume an existing native subagent with followup_task, but BB projects the child's next turn as foreground/root work. If the visible root finishes first, that misclassified child occupies the foreground slot and BB rejects the user's next prompt as a competing turn.

The child should remain attached to the root's delegation, and the next user prompt should still go to the root.

Versions and environment

• BB 0.40.0 desktop app; macOS 26.2 (25C56)
• Built-in provider-codex; Codex CLI 0.149.0
• Source repro: main at 31a190ddb5f0ffb86cb8dcd80482497663de2685

Human/UI reproduction

1. Open a BB thread using the Codex provider.

2. Ask the root to spawn a subagent named repro_child, wait for it to finish, and then finish the root turn.

3. Cause BB to recreate the provider session while preserving the same Codex rollout. Normally, leave the thread idle until the session is reaped, then return. Quitting/reopening or reconnecting can also exercise this boundary.

4. In the same root thread, send:

   Use followup_task to resume /root/repro_child. Ask it to keep working for at
   least 30 seconds, then finish your own response immediately without waiting.
   

5. As soon as the root response finishes, while the child is still running, send:

   continue
   

6. BB rejects the prompt as a competing turn. It should deliver the prompt to the root because the running child is delegated work.

Negative controls: this does not reproduce while the original translator remains live; replacing followup_task with send_message should not create another child turn.

Deterministic source-level reproduction

Add this test inside describe("codex subagent activity correlation", ...) in plugins/provider-codex/src/translator.test.ts. All identifiers are synthetic, and the helpers already exist in that block.

it("links a rawless resumed subagent when its child turn starts", () => {
  const harness = createHarness();

  expect(
    harness.translate(
      subAgentActivity({
        id: "synthetic-followup-call",
        kind: "interacted",
        agentThreadId: "synthetic-agent-thread",
      }),
    ),
  ).toEqual([]);

  const events = harness.translate(childTurnStarted("synthetic-child-turn"));
  expect(events).toContainEqual(
    expect.objectContaining({
      type: "item/started",
      item: expect.objectContaining({
        type: "delegation",
        childRef: "synthetic-agent-thread",
      }),
    }),
  );
  expect(events).toContainEqual(
    expect.objectContaining({
      type: "turn/started",
      parentToolCallId: harness.itemId("synthetic-followup-call"),
    }),
  );
});

Run:

pnpm --filter bb-plugin-provider-codex test -- translator.test.ts -t "links a rawless resumed subagent"

On unmodified main, the second assertion fails: the child turn is emitted without a delegation or parentToolCallId.

Expected vs actual

Actual: the resumed child is persisted without parent_tool_call_id, and the next user prompt can fail with:

Refusing to start a competing turn for thread "<synthetic-thread-id>" while another turn is active or starting

Expected: the resumed child turn carries its delegation's parentToolCallId. A later user prompt targets the root. send_message remains non-turn-producing, and genuine concurrent root turns remain rejected.

Evidence and root cause

The shared runtime correctly treats an unparented turn/started as foreground, so the competing-turn guard is behaving as designed. The provider projection is missing the parent link.

After translator recreation, the in-memory child map is empty. Current Codex app-server emits subAgentActivity(kind: "interacted") followed by the resumed child's turn/started, but does not forward the raw followup_task collaboration item on this path. The rollout contains the function call, but the app-server notification stream does not. BB currently discards an unknown child's interacted activity, so the following child turn is projected as root work.

An anonymized occurrence followed this sequence:

Event	Persisted result
Root calls followup_task; child starts	Child has no parent_tool_call_id and is stored as root work
Visible root completes	Misclassified child still owns foreground state
User submits the next prompt	Rejected as a competing turn
Child completes	Foreground slot clears

Scope

• Reproduces with a historical Codex child resumed after translator/session recreation.
• Does not require any particular project or workspace content.
• Is distinct from send_message, which emits the same interacted activity but starts no child turn.
• Is not fixed by Fix Codex and Claude subagent projection gaps #1361 because that correlation depends on the original translator's in-memory child map.
• Is not tell --mode auto injects into busy turn instead of queueing: provider error retry loop, status flips to error while turn continues #2370: that report has a genuinely busy/starting root; here delegated child work is misclassified as root work.

Candidate fix and validation: #2539

Suggested priority and effort (optional)

High priority: normal provider-session lifecycle can block new prompts in long-running Codex threads. The change is confined to Codex event correlation, regression tests, and the host-daemon protocol version; shared turn ownership and the competing-turn guard remain unchanged.

Checks

• Reproduced on the pinned main commit above.
• Searched open and closed issues for the same problem.
• Used only synthetic identifiers in this report.

AGENT GENERATED

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/2538.html

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): A recreated Codex translator ignores an unknown child interaction, so it emits the resumed child turn without its parent tool call.
• Linked PR review: Fix Codex subagent relinking after session resume #2539 → REQUEST CHANGES — The core fix passes, but unrelated gzip snapshot changes make the host daemon contract suite fail on supported Node 24.
• Proposed fix: Restore follow-up intent and child identity after translator recreation. Require a matched child turn, discard message-only events, and increment the protocol version.
• Caveats: The first install and one contract rerun hit shared /tmp inode limits. Shared dependencies and an isolated temporary directory let all required checks complete. No live provider turn was used.

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at the base commit, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by GPT-5.6-Sol

[peterfotinis]

Thanks for the independent reproduction and detailed review. I addressed both PR follow-ups in 74af01cc6:

• Reverted all six unrelated gzip byte changes. payload-size.test.ts is no longer part of the PR diff.
• Added the requested combined negative control, does not attach a rawless message to an unrelated multiplexed child. It verifies that a rawless send_message cannot steal a different known child's pending delegation on the multiplexed root thread, and cannot claim a later root turn.

Validation on the updated head:

• Codex provider: 244/244 tests passed
• Codex provider typecheck: passed
• Host-daemon contract on Node 24.18.0 / zlib 1.3.1: 51/51 tests passed
• Formatting and git diff --check: passed

For completeness, the changed gzip values came from Node 24.19.0 / zlib 1.2.12 producing different compressed byte counts for identical JSON. That confirmed the snapshot edits were environment-specific and unrelated to this fix, so the upstream expectations have been restored unchanged.