[Bug]: Agent-created thread reinterprets its handoff as a request to launch another thread #28986

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server — model-facing thread launch/handoff context

Steps to reproduce

1. In Codex thread A, ask the agent to do a bounded task in a separate thread/worktree.
2. A calls t3_thread_launch to create B. Its agent-authored initial message begins with historical context such as “User explicitly requests separate thread for [task]”, followed by instructions to implement the task.
3. B starts its first turn, interprets that historical request as a fresh launch instruction, explicitly calls t3_thread_launch to create C, then stops by reporting C instead of doing the work in B.

This pattern is observed in three existing recorded incidents, not a controlled deterministic reproduction. Model behavior is nondeterministic; no failure-rate claim is made. The user did not write B's opening prompt.

Expected behavior

B understands it is already the requested new thread and performs the assignment there. One user request for a new thread should not be reinterpreted by the receiving agent as authorization to create another.

Actual behavior

B creates another top-level thread/worktree and ends its first turn. Persisted history, read with t3_thread_read, confirms three examples in one local project:

In the latest incident B used a fresh clientRequestId and worktree workspaceStrategy. This is a new explicit model tool call creating a different thread, not a retry duplicating the same launch or a duplicate sidebar entry.

Impact

Major degradation or frequent failure: repeated unwanted threads/worktrees, extra provider turns, delayed work and manual user correction. Three observed incidents; frequency across all launches is unknown.

Version or commit

Local server-runtime.json reports serverVersion 0.1.6. Incidents observed November 1–2, 2026. Exact installed commit and desktop build not captured. Source inspection was against current main, not a claim that installed code equals main.

Environment

Windows, T3 Code through the Codex harness, gpt-6.1-sol with medium reasoning effort. Same-environment agent-created top-level threads in isolated Git worktrees. No cross-environment launch required.

Logs or supporting evidence

Common first-message metadata from all three incidents (sanitized):

{"type":"user_message","createdBy":"agent","creationSource":"mcp","senderThreadId":"<originating-thread-A>"}

Receiving thread metadata:

{"createdBy":"agent","creationSource":"mcp","parentThreadId":null,"relationshipToParent":null}

Thus agent authorship and sender provenance exist in app metadata, although the message is represented as a user_message. This does not establish exactly which provenance reaches the model in its provider request.

Investigation and limits

Read CONTRIBUTING.md, AGENTS.md and .github/ISSUE_TEMPLATE/bug_report.yml. Searched issue history including handoff/recursive, launches-another-thread and agent-authored searches; no exact match found.

Inspected current-main sources:

• https://github.com/pingdotgg/t3code/blob/main/apps/server/src/orchestration-v2/ThreadLaunchService.ts dispatches initialMessage.text and senderThreadId when supplied.
• https://github.com/pingdotgg/t3code/blob/main/packages/provider-core/src/server/orchestrationInstructions.ts restricts top-level launch to user requests, but does not explicitly distinguish a historical request embedded in a received launch brief from a fresh request to launch another thread.

Suspected boundary: agent-authored brief wording plus insufficiently explicit receiving-thread context. This does NOT prove T3 rewrites prompts, strips all provenance from provider requests, or has broken launch idempotency. Provider request envelopes were not captured; verifying how sender provenance is surfaced to the model remains investigation work.

No additional real-agent reproduction turns or servers were started: three persisted incidents already establish the behavior without creating more unwanted threads. No unrelated build/test suite was run for this report. If model-facing context is changed, a focused behavior eval with this incoming-brief pattern would fit AGENTS.md's evals/README.md guidance.

Related but different: #14115 concerns multiple servers resuming the same live threads. #18675 concerns cross-environment handoff return routes. This report concerns a receiving agent explicitly launching a new, different thread in the same environment.

Workaround

Proposed, not yet verified by a controlled test: write outgoing briefs as direct assignments and prefix “You are already in the requested new thread. Execute this task here; do not launch another thread.” Otherwise the user must manually correct the receiving agent for a prompt they did not author.

Prepared by gpt-6.1-sol through the Codex harness in T3 Code at the user's explicit request. Private project details, local paths and thread identifiers omitted.