Codex App sessions can be mislabeled as vscode

Summary

I’m seeing two likely-related but distinct issues on macOS:

1. Conversations started from Codex App can still be recorded with source: "vscode" in local session metadata.
2. Even after disabling/uninstalling the VSCode ChatGPT/Codex extension and clearing local VSCode pairing files, pure Codex App conversations still hit websocket streaming failures such as:

• stream disconnected before completion: Operation timed out (os error 60)
• Reconnecting... 2/5
• responses_websocket timeout symptoms

This makes it look like there may be:

• a session source attribution bug, and
• a separate shared websocket/streaming timeout issue in the Codex App/Desktop path itself.

Environment

• macOS
• Recent Codex App build
• Recent Codex CLI alpha build seen in local session metadata

What I verified

A. Sessions started from Codex App were marked as source: "vscode"

In several local .jsonl session files, the metadata showed:

• originator: "Codex Desktop"
• but also source: "vscode"

That seems inconsistent, especially for App-launched conversations.

B. The VSCode extension path also showed separate issues during investigation

Before cleanup, the VSCode extension logs showed:

• repeated:
• Received broadcast but no handler is configured method=thread-stream-state-changed
• and explicit websocket failures:
• failed to connect to websocket: IO error: Operation timed out (os error 60), url: wss://chatgpt.com/backend-api/codex/responses

So the VSCode extension path does appear to have its own problems as well.

C. But pure Codex App still reproduced the timeout after VSCode cleanup

I then did a stronger isolation test:

1. Quit VSCode
2. Disabled/uninstalled the VSCode OpenAI/Codex extension
3. Cleared local pairing files under the Codex App pairing directory for Visual Studio Code
4. Verified that the pairing directory was empty
5. Opened only Codex App
6. Started a fresh conversation in Codex App and sent a long streaming prompt

Even in this cleaned state, the App still got stuck and then showed:

• Reconnecting... 2/5
• stream disconnected before completion: Operation timed out (os error 60)

So this no longer looks like “Codex App is only failing because it reused the VSCode plugin websocket path”.

Repro prompt

I used a simple long-streaming prompt to make the issue easier to trigger:

Please continuously output the numbers 1 through 3000.
Requirements:
- Put 10 numbers on each line, separated by spaces
- Do not explain anything
- Do not omit anything
- Continue until you reach 3000

Desktop/App timeline example

For a fresh App conversation after the VSCode cleanup:

• conversation created successfully
• turn/start succeeded
• about 30 seconds later, thread title generation already timed out:
• Failed to generate thread title
• Timed out waiting for structured result.

This suggests the request was accepted, but the downstream structured/streaming path stalled very early.

Expected

• A conversation started from Codex App should not be labeled as source: "vscode" unless it truly originated from the VSCode integration.
• After removing VSCode extension influence and clearing pairing files, pure Codex App should not continue hitting the same websocket timeout path if the problem were VSCode-specific.
• UI should distinguish:
• model streaming
• reconnecting
• waiting for approval
• websocket timeout / retry

Actual

• Some Codex App conversations appear mislabeled as source: "vscode"
• Pure Codex App still experiences websocket/stream timeout behavior
• UI surfaces this mainly as reconnecting / stuck behavior

My current conclusion

This looks like two separate bugs:

1. Session source attribution bug

• App-started sessions can be misclassified as vscode

1. Shared websocket streaming timeout bug

• The Codex App/Desktop path itself can hit responses_websocket / os error 60
• This is not eliminated by removing VSCode integration

Related issues

This may overlap with:

• #13713
• #5575
• #3355
• #7623
• #13583
• #13343
• #5196

But this report adds a stronger isolation result: pure Codex App still reproduces after removing VSCode integration artifacts.

If useful, I can provide additional timestamps and local logs privately.