Codex Desktop: misleading “project/workspace” defaults + silent failure when no local workspace or Cloud repo access

What version of Codex CLI is running?

Codex Desktop (macOS) — Version 26.325.31654

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Terminal

What issue are you seeing?

Codex Desktop’s initial “project/workspace” behavior and defaults create confusing onboarding and can lead to silent failures. Codex is described as enabling “seamless local ↔ cloud handoff” across surfaces , but in the Desktop app the experience is not seamless when a local workspace isn’t set or when a repo isn’t enabled for Cloud access.

Why this matters
Codex is positioned as a repo-aware coding agent that “navigates your repo to edit files, run commands, and execute tests” . Because repo context is required, the app should never accept prompts and then drop them, and should clearly explain what context is missing and how to fix it.

Observed behavior (issues)
1) Local mode + no selected workspace can silently drop prompts

• If there is no selected local workspace/project (e.g., after deleting the prior project/workspace), entering a prompt can result in no response (the prompt appears to be dropped with no error).
• The app later creates/uses a default “Playground” workspace to recover.

2) Cloud mode appears to “default” to an unexpected repo (often public/available)

• When switching to Cloud, the app can attach to a repo context the user did not explicitly select in the Desktop app.
• This can present misleading Git state (e.g., showing main) even when the visible “Playground” workspace is unrelated.

3) When Cloud handoff can’t access a repo, the Desktop UX doesn’t explain the real cause

• Cloud repo availability depends on what the ChatGPT GitHub app is allowed to access; users must configure repository access via the GitHub app configuration (Gear icon / install settings) .
• If the needed repo isn’t enabled, Cloud handoff can fail in a way that isn’t explained in-product.

What steps can reproduce the bug?

Uploaded thread: 019d5638-e5ec-7f71-98fb-c9ca2677e64d

A) Silent failure in Local

1. Open Codex Desktop on macOS.
2. Ensure mode is Local.
3. Delete the only workspace/project (or otherwise end up with no selected local workspace root).
4. Type a simple prompt and submit.

B) Confusing defaults in Cloud

1. Open Codex Desktop.
2. Switch mode to Cloud.
3. Observe the selected repo/branch context can change to an unexpected repo (e.g., showing main) without an explicit “repo attach” step.

What is the expected behavior?

Expected results

• If no local workspace root is selected in Local: show a blocking, explicit message like “Select a local folder to use as the workspace” (and provide a single-click action).
• If Cloud can’t access the repo needed for the environment: show a clear error that repository access must be enabled for the ChatGPT GitHub app, and deep-link to the GitHub app configuration page (Gear) .
• “Playground” should be obviously non-repo-bound (or explicitly show what repo/environment it is bound to), so users aren’t misled by branch indicators.

Actual results

• Prompts can be silently dropped when Local has no workspace selected.
• Cloud mode can attach to repo/branch context unexpectedly.
• The UI does not clearly explain that Cloud repo availability depends on GitHub repository access configuration.

Additional information

Suggested fixes
1) Never silently drop a prompt: if required context is missing, block send + show a clear call-to-action.
2) Make workspace binding explicit: always display the local path (Local) and environment+repo binding (Cloud) in a consistent, discoverable place.
3) Improve Cloud handoff messaging: if repo isn’t enabled for the GitHub connector, show the exact reason and link to the Gear/app config flow .
4) Terminology/UI: if “project” = “local folder workspace root,” label it that way (Codex is a repo-first agent ).