Codex Desktop can apply a concurrently created child task title to its parent

What version of the Codex App are you using?

The Desktop build number is not exposed to the remote task context. The connected remote host is running codex-cli 0.149.0.

What subscription do you have?

Not included in the remote task metadata.

What platform is your computer?

Codex Desktop on macOS, coordinating a Remote SSH task on Apple silicon.

What issue are you seeing?

A parent Codex task running gpt-5.6-sol temporarily received the exact title intended for one of two concurrently-created gpt-5.6-luna child tasks.

This is a title-attribution/state-routing bug, not a model switch:

• The parent was created with model: "gpt-5.6-sol" and an explicit Sol title.
• The parent's persisted first-turn runtime metadata remained gpt-5.6-sol.
• The parent then issued two create_thread calls concurrently with Promise.all.
• The second child requested the title ↳ ⏳ Luna исследует DEV deploy контур.
• The parent header and sidebar later displayed that exact child title, even though the visible conversation content and runtime still belonged to the Sol parent.
• A later runtime-aware set_thread_title restored the parent's model label. During recovery, read_thread and list_threads briefly disagreed before converging.

No repository code or task prompt changed the parent's runtime model.

Steps to reproduce

1. Start a visible parent task with an explicit title and model:

``js
create_thread({
model: "gpt-5.6-sol",
title: "↳ ⏳ Sol parent task",
// normal project/worktree target
})
``

1. In that parent, concurrently create two visible child tasks with distinct explicit titles:

``js
await Promise.all([
create_thread({
model: "gpt-5.6-luna",
title: "↳ ⏳ Luna child A",
// normal project/worktree target
}),
create_thread({
model: "gpt-5.6-luna",
title: "↳ ⏳ Luna child B",
// normal project/worktree target
})
])
``

1. Observe the parent header and sidebar while both children initialize and title events propagate.
2. Compare:

• parent runtime metadata,
• parent read_thread,
• parent row returned by list_threads,
• both child thread IDs and titles.

Expected behavior

Each title update must be scoped to the exact thread returned or reserved by its own create_thread call. Creating or renaming a child must never change the parent's title. Concurrent child creation should be safe.

Actual behavior

The parent temporarily displayed the exact title of child B. Runtime provenance still identified the parent as gpt-5.6-sol.

Impact

• Users can believe the wrong model is executing a task.
• Orchestrators that use titles as operational cues can make unsafe routing or cleanup decisions.
• Parent/child task identity becomes ambiguous in the sidebar and deep links.
• Runtime-aware repair can hide the original corruption before diagnostics are collected.

Confirmed evidence

Observed on 2026-08-22 around 10:33 UTC:

• Parent runtime: gpt-5.6-sol.
• Parent creation request: explicit Sol title.
• Two child creation requests: concurrent Promise.all, both gpt-5.6-luna.
• Wrong parent title: byte-for-byte equal to the second child's requested title.
• Parent and child thread IDs were distinct.
• The parent conversation content and execution remained the Sol task.
• Explicit title repair succeeded; list/read state then converged.

The report intentionally omits private prompts, repository paths, account identifiers, and full thread IDs. Those can be supplied privately to OpenAI Support if needed.

Root-cause hypothesis (inference, not confirmed)

A title/cache event emitted during concurrent create_thread initialization may be reduced under the active/calling thread instead of the returned child thread ID, or an optimistic title update may be keyed by the current view rather than the reserved child identity.

Suggested fix and regression test

• Bind every optimistic and persisted title mutation to the target threadId or reserved clientThreadId, never the currently active thread.
• Validate the source/target thread identity before applying renderer/sidebar title events.
• Make concurrent create_thread responses and title events independently correlated.
• Add an integration test:

1. Create parent P with title P.
2. Concurrently create children A and B with titles A and B.
3. Deliver completion/title events in both normal and reversed order.
4. Assert P remains P, A remains A, B remains B in persisted state, read_thread, sidebar/list state, and deep-link header.