[ChatGPT Desktop][macOS][Voice] Voice launched from a Project becomes Projectless and loses its origin #40703

Summary

In the current ChatGPT Desktop app on macOS, starting realtime Voice from Work while an existing Project is selected creates the Voice task in a generated Projectless workspace.

The Voice assistant cannot identify the Project from which it was launched. Manually moving the resulting Voice task under that Project in the sidebar changes its visual placement, but does not change its working directory or restore the originating Project context.

Environment

• Application: ChatGPT Desktop
• Surface: Work → selected Project → realtime Voice
• App version: 26.820.60940 (build 7119)
• Platform: macOS 26.6.2, Apple Silicon (arm64)
• Date reproduced: August 25, 2026
• Feedback correlation reference: 01a03aaa-755e-7a41-98b1-b1cb1d02eaa5
• Feedback receipt state: NOT_PROVED because Voice did not show a final submission confirmation

Steps to reproduce

1. Open ChatGPT Desktop.
2. Select Work.
3. Select an existing Project.
4. From the Project composer, start a new realtime Voice chat.
5. Ask the Voice assistant which Project launched it.
6. Inspect the Voice task's working directory.
7. Manually move the Voice task under the intended Project in the sidebar.
8. Inspect the working directory again and ask about the Project of origin.

Actual behavior

• The Voice task is created in a generated Projectless workspace such as Documents/Codex/<date>/realtime-voice-chat.
• The Voice assistant cannot identify the Project from which it was launched.
• It cannot establish that Project files, instructions, or context were inherited.
• Manually placing the task under the Project changes only the sidebar grouping.
• The active Voice task keeps the generated Projectless working directory after the move.
• The UI does not explain that the visible Project placement and runtime Project association are different.

Expected behavior

A Voice chat started from a selected Project should preserve the originating Project relationship.

If Voice must use a separate operational workspace, it should still retain and expose enough origin metadata for the assistant and UI to state:

• which Project launched the Voice task;
• whether Project files and instructions were inherited;
• which working directory is active; and
• what a manual move into a Project does and does not change.

At minimum, the assistant should be able to say that the Voice task was launched from the selected Project even if Voice intentionally runs in a separate workspace.

Why this matters

The current behavior creates a misleading state: the sidebar can show the Voice task inside a Project while its runtime remains Projectless. Users may reasonably believe Project instructions, files, and boundaries are active when they are not.

The assistant also gives an incorrect or incomplete answer when asked where it was created because the Project-of-origin relationship is missing.

Documentation basis

Official OpenAI documentation says Projects organize related chats and provide shared context. It also says new chats in a local Project start in the primary folder:

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

The Voice documentation says Voice operates in Chat, Work, and Codex, but does not document that Voice launched from a Project will discard the Project relationship:

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

The exact Voice-specific inheritance rule is therefore a SOURCE GAP, while the observed Projectless runtime behavior is directly reproduced.

Related issues and current-report distinction

• New realtime voice chats start projectless instead of attaching to the selected project folder #36195 reports the earlier general symptom of realtime Voice chats starting Projectless.
• This independent report documents the current ChatGPT Desktop build, the assistant's inability to identify the originating Project, and the additional finding that manually moving the Voice task into the Project changes visual grouping but does not repair the runtime working directory or Project context.
• [ChatGPT Desktop][macOS][Voice] /feedback does not show a final success or failure confirmation #40701 tracks the separate Voice /feedback confirmation defect encountered while reporting this behavior.

Privacy

The full screenshots are intentionally not attached because they display private Project and task names. No logs, private conversation content, account details, or exact local paths are included.

Validation / close criteria

• A Voice task launched from a Project retains an observable link to that Project.
• The Voice assistant can accurately identify the originating Project.
• The UI clearly distinguishes sidebar placement from runtime working directory and inherited Project context.
• Manual reassignment either updates the runtime association or explicitly states that it is visual-only.
• Project files and instructions are either inherited as expected or their absence is clearly disclosed.

Update — August 29, 2026: Local Project no-workaround path and current build

This remains reproducible in ChatGPT Desktop 26.825.41651 (build 7345) on macOS 26.6.2.

Current Local Project reproduction

1. Select an existing Local Project in ChatGPT Desktop.
2. From that Project context, create a new task and start realtime Voice before sending a normal typed message.
3. Observe that the Voice task is created in a generated Projectless workspace rather than retaining the selected Local Project relationship.
4. Confirm that the Voice assistant cannot prove that the Local Project's files, instructions, or origin metadata were inherited.

The current reproduction again produced a Projectless Voice task even though Voice was started while the Local Project was selected.

Documented no-workaround path

The official Voice documentation says a chat or task must begin in Voice mode; a chat or task that starts in another mode offers voice dictation instead:

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

That creates a no-workaround loop:

• Creating a normal task inside the Local Project first does not provide a later path to turn that existing task into realtime Voice.
• Starting the new task directly in realtime Voice while the Local Project is selected reproduces this issue and creates a Projectless Voice task.

Therefore, “create the Project task first, then enable Voice” is not an available workaround under the documented product behavior. The product either needs to preserve the selected Local Project when Voice creates the task, or clearly disclose and expose the separate runtime association before Voice begins.

Privacy: no private Project names, task content, local paths, logs, screenshots, diagnostics, or legal material are included in this update.