[Windows / ChatGPT Projects] New Chat first response fails with conversation_inaccessible 404; Work in the same project succeeds

What version of the Codex App are you using (From “About Codex” dialog)?

Windows package OpenAI.Codex_26.908.4834.0_x64, identified from the running application's startup log (package version, not a reading of the About dialog). The failure occurs in ChatGPT → Chat in the unified desktop app.

What subscription do you have?

ChatGPT Plus.

What platform is your computer?

Windows x64, OS version 10.0.26200, build 26200.9445, display version 25H2.

What issue are you seeing?

In an existing ChatGPT project, creating a new ordinary Chat and sending a trivial first message creates the conversation/sidebar entry and persists the user's message, but no assistant answer appears. The UI displays Error in message stream with a Retry button.

For the fresh desktop reproduction on September 14, 2026, the log records HTTP 404 conversation_inaccessible for both a conversation fetch and POST /conversation/init, immediately after the new conversation route is assigned. A subsequent refetch completes but leaves the UI conversation in error state.

The project remains visible and its other conversations are listed. Reading the failed conversation later retrieves the user message but no assistant response.

Earlier same-day browser tests of this affected project also reproduced the Chat failure. A control Chat outside the project answered successfully, and Work inside the same project answered successfully. This is not established to affect all projects.

What steps can reproduce the bug?

1. Sign in to the desktop app and select ChatGPT.
2. Open the affected existing ChatGPT project.
3. Start a new conversation in ordinary Chat mode.
4. Send a minimal message. The latest desktop test used тест (Russian for “test”).
5. Observe the new conversation in the project's sidebar, with the user message visible and Error in message stream instead of an assistant answer.

Earlier same-day controls and troubleshooting:

The successful Work test's saved conversation was subsequently read and the completed assistant response confirmed. These control tests preceded the fresh desktop log capture; no claim is made that Work resolves the underlying Chat defect.

What is the expected behavior?

The owner should be able to receive an answer to the first message in a newly created Chat inside an accessible project. If conversation initialization or authorization fails, the UI should expose an actionable error rather than only a generic stream failure.

Additional information

Sanitized excerpt from the desktop log; all conversation IDs refer to the same newly created test conversation and have been replaced with <conversation-id>. Only relevant fields are retained:

2026-09-14T17:47:43.230Z
sa_server_request_failed method=get
routePattern=/conversation/{conversation_id}
status=404 errorCode=conversation_inaccessible
can_retry=false

2026-09-14T17:47:43.324Z
sa_server_request_failed method=post
routePattern=/conversation/init
status=404 errorCode=conversation_inaccessible
can_retry=false

2026-09-14T17:47:43.348Z
sa_server_request_failed method=post
routePattern=/conversation/init
status=404 errorCode=conversation_inaccessible
can_retry=false

2026-09-14T17:47:45.164Z
chatgpt_conversation_refetch_started
conversationId=<conversation-id>
reason=explicit_update statusBefore=error

2026-09-14T17:47:45.678Z
chatgpt_conversation_refetch_completed
conversationId=<conversation-id>
currentNodeApplied=false mappingSize=10 snapshotMappingSize=2
statusBefore=error statusAfter=error

The server's error message says the conversation is inaccessible and suggests checking the account. This is an observed error, not proof that an account mismatch is the root cause. The underlying reason for the failed initialization remains unknown.

Related reports reviewed before filing:

• #45259: existing project chats cannot be accessed in desktop/web. Potentially related, but does not document a new Chat's first-message failure or the Chat-versus-Work control.
• #34300: missing creation/move controls for ordinary Chat in projects. Here the conversation is created and the first response fails.
• #39202: an ongoing ordinary Chat generation stops after a WebSocket timeout; this report concerns first-message initialization in an affected project.

Project name, project/conversation IDs, private conversation links, unrelated chat titles, account identifiers, local user paths, and raw screenshots/logs are intentionally omitted.

Start by reproducing a new Chat inside an existing project on the Windows desktop app, then inspect the desktop log around GET /conversation/{conversation_id} and POST /conversation/init. Compare the failing Chat flow with the successful Work and out-of-project controls, including the refetch state transitions. Done means the first message receives an assistant response, or an initialization or authorization failure is shown as an actionable error rather than only a generic stream failure.