codex - 💡(How to fix) Fix Cloud chat converted locally attaches to active local project instead of original project

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When converting or continuing a cloud Codex chat locally from an existing project, Codex appears to attach the chat/session to the currently active local project rather than the original project associated with the cloud chat.

This only behaves correctly when the original project is the only currently active local project.

Root Cause

When converting or continuing a cloud Codex chat locally from an existing project, Codex appears to attach the chat/session to the currently active local project rather than the original project associated with the cloud chat.

This only behaves correctly when the original project is the only currently active local project.

RAW_BUFFERClick to expand / collapse

Summary

When converting or continuing a cloud Codex chat locally from an existing project, Codex appears to attach the chat/session to the currently active local project rather than the original project associated with the cloud chat.

This only behaves correctly when the original project is the only currently active local project.

Expected behavior

A cloud chat that originated from Project A should convert/continue locally in Project A, regardless of which other local project is currently active.

If Codex cannot safely determine the target project, it should prompt the user to confirm the local project/workspace before attaching the chat.

Actual behavior

When another local project is active, the cloud chat is forcibly brought into that active local project, even when that project is different from the original project.

This can cause confusion and may risk applying edits or context to the wrong local workspace.

Reproduction steps

  1. Have at least two local Codex projects available, Project A and Project B.
  2. Start or have an existing cloud Codex chat associated with Project A.
  3. Locally switch Codex so Project B is the active local project.
  4. Convert or continue the cloud chat locally.
  5. Observe that the chat/session attaches to Project B instead of Project A.

Environment

  • App: Codex Desktop
  • OS: Windows
  • Codex Desktop app package: OpenAI.Codex_26.519.3891.0
  • Codex Desktop product version: 26.519.31651
  • Codex CLI / agent binary: 0.133.0-alpha.1
  • Git for Windows: 2.54.0.windows.1
  • Local workspace location includes Google Drive-backed folders

Notes

This seems related to workspace/repo routing or stale active-project state. Similar existing reports include:

  • #5057, where cloud task creation can target the wrong repo
  • #10547, involving cloud/local state confusion
  • #21076, involving stale or incorrect project/thread history state

The core concern is that Codex seems to prioritize the current active local project over the cloud chat's original project identity when converting/continuing the chat locally.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

A cloud chat that originated from Project A should convert/continue locally in Project A, regardless of which other local project is currently active.

If Codex cannot safely determine the target project, it should prompt the user to confirm the local project/workspace before attaching the chat.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING