Windows: Voice Chat Fork loses parent project context, model selection, and AGENTS startup behavior

Open 💬 6 comments Opened Aug 18, 2026 by mrybicki-enmark

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex desktop app on Windows: 26.814.5167.0
Model selected in the parent task: GPT-5.6 Terra, Medium reasoning

What platform are you using?

Windows desktop app.

What issue are you seeing?

Starting Voice Chat from a new task created in a multi-folder Codex project creates a separate Voice Chat Fork that does not preserve the parent task's effective project context.

In this reproduction, the parent task was started in an All Repos project with 2 configured source folders:

C:\Github
a separate shared coordinator folder

The parent task showed GPT-5.6 Terra with Medium reasoning selected. After clicking the Voice Chat button:

The child is titled Voice Chat Fork.
The child composer shows GPT-5.6 Terra Light, rather than the parent's Medium selection.
The child does not follow the parent's/global AGENTS.md startup instruction when greeted with the coordinator activation phrase.
Instead of performing the required context load and task rename, Voice responds generically.
Inspection of the resulting task shows it running from a generated realtime-voice-chat-* workspace rather than retaining the parent project workspace.

The failure is visible on the first voice reply, before any project work begins. The child still displays Full access, so this is not explained by a missing sandbox permission.

This was observed immediately after updating the desktop app on August 18, 2026. The same workflow previously preserved the expected coordinator behavior.

Steps to reproduce

Create or open a multi-folder Codex project with a root AGENTS.md instruction that has a distinctive first-message behavior.
Start a new task in that project and select a non-default model/reasoning combination.
Click the Voice Chat button in the task composer.
In the Voice Chat Fork, say the distinctive activation phrase from AGENTS.md.
Compare the parent and child:

selected model/reasoning;
effective project/source-folder context;
first-response behavior.

Expected behavior

Voice Chat should remain attached to the task that launched it, or its fork should inherit all relevant task configuration:

multi-folder project and source folders;
effective AGENTS.md instructions;
selected model and reasoning effort;
sandbox/access configuration;
task-level startup behavior.

If Voice Chat intentionally creates an isolated task, the UI should clearly state that it will not inherit project context and should offer an option to retain it.

Actual behavior

The Voice Chat Fork appears to receive a generated workspace and a different model/reasoning setting. It ignores the parent task's visible project-specific behavior on its first response.

Why this matters

For workflows that use AGENTS.md as durable startup context, Voice Chat becomes unreliable: the user has to re-explain identity, project scope, and operating rules after starting voice. It also creates a risk that voice work runs under a different model/reasoning setting than the task the user explicitly configured.

Additional information

I can provide screenshots showing the parent All Repos task with Terra Medium selected and the resulting Voice Chat Fork with Terra Light selected. I can also provide task identifiers privately if useful; they are omitted here because they are local task metadata.

This is distinct from tool-handler failures during Realtime Voice. The problem occurs at Voice Chat Fork creation and is observable immediately in the first reply.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 9 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#37950

Powered by Codex Action

mrybicki-enmark · 9 days ago

Update: Voice cannot be restarted after a normal stop

A second reproduction shows a related failure in the same All Repos task:

Start a normal All Repos text task.
Start Voice Chat successfully.
End the voice session normally.
Attempt to start Voice Chat again in that same task.

Actual result: Voice cannot be started again. The task itself remains healthy and idle. The first voice session is recorded as ending normally, but no second voice-start event reaches the task, which suggests the failure occurs in the desktop voice launcher or session-attachment layer before task execution begins.

This matters because voice is the primary interaction mode for this workflow; a user cannot reliably pause and resume voice in the same task.

mrybicki-enmark · 9 days ago

Update: the successful-stop signal leaves the task stuck in active-call UI state

A controlled stop was requested from the working task. The app reported that Voice ended successfully. Immediately afterward, the composer still displayed the stop-square control where the microphone should be, indicating that the UI still considered Voice active.

The task could no longer start a new voice session. This is stronger than a failed restart: the stop operation itself appears to leave the task's local Voice state stuck. Screenshot available privately.

mrybicki-enmark · 9 days ago

Update: archiving a failed Voice task returns “thread not found”

After the Voice restart failure, attempting to archive the affected task from its own conversation produced a visible error stating that the thread could not be found.

The conversation is still visible in the UI, but its task record cannot be resolved for archiving. This corroborates the earlier direct archive failure and indicates that the Voice failure can leave orphaned or inconsistent local task state.

Screenshot available privately; it shows the archive request followed by the “thread not found” error.

mrybicki-enmark · 9 days ago

Update: Voice stop leaves the task unable to render normal replies or start Voice again

This is now reproducible beyond Voice itself:

In an existing All Repos task, start Voice normally.
Ask the assistant to stop Voice.
The stop operation reports success, but the task remains stuck in the stop-square state.
Normal typed messages sent afterward are processed and their replies are generated, but the desktop UI does not render them until the entire app is fully exited and reopened.
After reopening, those delayed replies appear. The affected task still cannot start another Voice session; the control remains a play/start button rather than reconnecting Voice for that task.

Local evidence from the affected task:

The Voice-call creation request succeeded.
The backend stop operation returned ended: true.
Subsequent normal response turns completed after Voice was stopped.
The local client log records repeated WebSocket incremental-request reuse mismatches on those turns.
No server-side error was returned to the user.

Impact: this is not a normal “start a new chat” situation. A long-running coordinator task becomes partially unusable: Voice cannot resume and ordinary replies are invisible until an app restart. Restarting often recovers rendering, but not Voice for the affected task.

mrybicki-enmark · 9 days ago

I'm sorry - one last post about this. It's not isolated to Voice. Once a chat becomes corrupted, anything I type looks like it's being ignored but if I close and reopen the application completely, the response is there. So having to close and reopen a chat to get a reply is a huge impediment for me. And now I have to hand off conversations to new conversations once they become corrupted.

What was interesting about this time is trying to reproduce it and closing and reopening the app multiple times eventually it fixed itself (see below) but it says it reported itself with details before my last restart...