New realtime voice chats start projectless instead of attaching to the selected project folder

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

• #35452

Powered by Codex Action

Confirmed on Windows as well.

I can reproduce the same behavior in the Windows desktop app: if I open an existing Project and start a new realtime Voice session from inside it, the newly created conversation is moved to Recents and is no longer associated with the Project.

To keep working with that Voice conversation in the intended Project, I have to manually move the conversation back into the Project and then start Voice again.

This suggests the issue is cross-platform rather than macOS-specific.

Duplicate report: #37469

Still reproducible on macOS with Codex Desktop 26.803.61601 (released Aug 8, 2026).

I’m seeing the same behavior: starting a new realtime Voice chat from inside an active local project creates the Voice task in a generated projectless workspace rather than inheriting the active project.

This is blocking my use of Voice as a project-level orchestration/control-room interface, because the Voice session loses the repository/project context it was launched from.

I reproduced this on macOS with Codex Desktop 26.803.61601 (released Aug 8, 2026) and did some investigation into the local persistence behavior. I also have a working local workaround that may help identify the underlying issue.

What I found

When a realtime voice chat is created from an active local project, its session record appears to persist the generated projectless workspace as its cwd, e.g.:

~/Documents/Codex/<date>/realtime-voice-chat-N

rather than the project root from which Voice was launched.

The relevant session record is under:

~/.codex/sessions/<date>/rollout-...-<thread-id>.jsonl

Project assignment state also appears in:

~/.codex/.codex-global-state.json

including:

• thread-project-assignments
• projectless-thread-ids
• workspace-root hints

Editing only the project assignment in .codex-global-state.json did not persist. After Codex was relaunched, the thread reverted to projectless.

Working workaround

With Codex completely closed, I tested the following:

1. Rewrite the voice thread's cwd fields in its session JSONL to the actual project root.
2. Add the thread to thread-project-assignments.
3. Remove it from projectless-thread-ids.
4. Update its workspace-root hint to the project root.
5. Relaunch Codex.

The Voice thread then remains associated with the correct project. I verified that the assignment survives multiple full quit/relaunch cycles.

The workaround script refuses to operate while Codex is running and backs up every file before modification.

This suggests that the session's persisted cwd may be involved in Codex re-deriving the thread's project association at startup, rather than .codex-global-state.json being the authoritative source by itself.

Possible fix direction

Based only on this external observation, it appears that when a realtime Voice thread is created from an active local project, initializing that thread's session cwd to the originating project's workspace root — rather than creating it under the projectless ~/Documents/Codex/... workspace — may prevent the project association from being lost in the first place.

One limitation of the workaround: it only repairs the thread after the Voice session. During the live Voice session, the agent really is operating from the generated projectless workspace, so the workaround cannot retroactively restore the project context that was missing during that session.

No Codex binaries were modified; this was entirely done by inspecting and editing the local ~/.codex session/state files.

(This investigation and workaround were produced with Claude Fable 5. I’ll await OpenAI’s reimbursement for the token spend. ;))

I can reproduce the same failure with an organizational folder, not only a local project.

Steps:

1. Create a new chat under the “my_project” folder in Codex Desktop.
2. Convert that new chat to realtime voice chat.
3. Observe that the conversation leaves “my_project” and becomes a separate “New voice chat” task.

Expected: the voice chat should remain under the folder where the original chat was created, so I can create and organize voice chats within “my_project”.

Actual: converting to voice chat discards the folder association.

Broader product expectation: this should work for every user and every project or folder, not only for the specific “my project” example.

A user should be able to start realtime voice chat from any project or folder. The voice chat should be created inside that selected project context and automatically inherit its files, instructions, memory/workflow setup, and continuity. It should not create a separate projectless “New voice chat” that requires the user to manually redirect it back to the project afterward.

“My project” is only one concrete reproduction example; the requested behavior is general project-linked voice chat for all users.

Happening with me also.

Title: Two-way Live Voice creates a projectless fork instead of inheriting the selected Codex project

Environment:

• macOS Darwin 25.6.0 arm64 arm
• Codex desktop app 26.814.41407, build 6720
• Local Codex projects

Feedback already submitted: Feedback ID: 01a01e55-baae-7b32-acd1-f66cbf1979c7

Still reproducible on macOS with ChatGPT Desktop 26.820.60940 (build 7119) on macOS 26.6.2 (arm64).

New reproduction details

1. In Work, select an existing Project.
2. Start a new realtime Voice chat from the Project composer.
3. Ask the Voice assistant which Project launched it.
4. The Voice task runs from a generated Documents/Codex/<date>/realtime-voice-chat workspace and cannot identify the originating Project.

Manual reassignment does not restore runtime context

After creation, manually moving the Voice task under the intended Project changes the sidebar grouping, but the active task still reports the same generated projectless working directory. The Voice task therefore remains unable to establish that it inherited the Project's files, instructions, or origin metadata.

This adds a distinction between:

• visual Project placement in the sidebar; and
• runtime Project association / working directory / inherited context.

At minimum, if Voice intentionally uses a separate workspace, it should retain and expose the originating Project identity so the assistant can accurately say where it was launched and the UI can disclose which context was or was not inherited.

The official Projects documentation says Projects give chats shared context and that new chats start in the primary folder; the Voice page does not document an exception for Voice-created tasks:

• https://learn.chatgpt.com/docs/projects
• https://learn.chatgpt.com/docs/features/voice

Feedback correlation reference: 01a03aaa-755e-7a41-98b1-b1cb1d02eaa5. The Voice /feedback flow did not show a final success confirmation, so receipt of that feedback is NOT_PROVED. That distinct Voice feedback-confirmation defect is tracked in #40701.

The full screenshots are intentionally omitted because they show private Project and task names.