Codex app sidebar navigation can strand the current task without warning

Open 💬 2 comments Opened Jul 14, 2026 by Artis246

Product surface

Codex / ChatGPT desktop app on macOS.

Problem

Clicking any task in the left sidebar immediately moves the user and Codex into a different conversation and point in the project's history. The app does not first explain that the click is a context/timeline switch, confirm that the current task is durably recoverable, or make it obvious how to return to the exact state that was just active.

Sidebar task names are not reliable enough to identify the actual project, work state, or point in time. This makes ordinary navigation behave like an unguarded timeline switch.

A user's description captures the severity: it feels "like walking around in a concert with a handgun in the air with the safety off." One accidental click can carry catastrophic context-loss potential with no guardrail.

Real incident and impact

The user successfully brought Codex and Grok together for a live collaborative meeting. Codex was working in the desktop app while Grok remained in a signed-in Safari conversation. The collaboration produced valuable work, and the user had explicitly asked Codex to save it.

After the meeting, the user accidentally touched an item in the Codex sidebar. Both the user and Codex were transported into a task from roughly three months earlier. Grok was not affected and remained in the correct current Safari conversation. Codex then appeared to have amnesia because the old task did not contain the meeting or the context that led to it.

The user spent approximately three hours recovering. First, they located and protected the material Codex had saved from the meeting. Then they worked with the older-context Codex to reconstruct the missing present-day state. Finally, they returned to Grok's still-current Safari conversation, reviewed the full lead-up, and manually supplied that context back to Codex.

There is no evidence here of a server outage or a Grok failure. The failure is unguarded navigation between radically different task histories, with no warning proportional to the context discontinuity and no reliable one-step return to the state just left.

Expected safeguards

  • Atomically persist and verify recoverability of the current task before switching sidebar items.
  • Warn that selecting another sidebar task changes the active conversation history and agent context.
  • If persistence or indexing has not completed, block navigation or show an explicit confirmation.
  • Clearly identify the current task's project, last activity time, historical position, and durable-save status.
  • Provide a reliable one-step back/history path to the exact state active before navigation.
  • Detect stale or misleading task titles and show canonical project identity separately.
  • Expose an obvious recovery action when a user lands in an older task state.
  • Never make the user responsible for manually reconstructing hours of agent context after an accidental click.

Privacy

This report intentionally omits private project content, account data, and session transcripts.

View original on GitHub ↗

2 Comments

Artis246 · 1 month ago

Additional recurring detail from the affected user:

After an accidental sidebar jump, the sidebar provides no practical way to identify the state that was just left. There are no visible timestamps, the displayed names frequently do not match the actual project or work context, and many entries can have the same or nearly identical name. A sidebar containing a dozen indistinguishable entries is not a recovery mechanism.

The UI should show, for every task:

  • canonical project identity and path;
  • exact last-active timestamp;
  • whether it is the currently active/latest task;
  • durable-save/indexing status;
  • enough unique context to distinguish repeated automation/task names;
  • a guaranteed "return to the task I just left" action.

Without those signals, the user cannot determine where they were in time after the app has already switched contexts.

Artis246 · 1 month ago

The recovery attempt itself compounds the risk.

When the user tries to locate the task they just left, each candidate sidebar click immediately performs another full context switch. Because entries may be indistinguishable and lack timestamps, choosing the wrong candidate can strand the rescue path again. From the user's practical perspective, one bad recovery guess can make the current state disappear permanently from view.

Recovery therefore needs to be non-destructive:

  • preview task identity, timestamp, project, and recent context before activating it;
  • preserve a navigation breadcrumb/back stack independent of task history;
  • provide immediate undo after every task switch;
  • keep the task just left pinned as a recoverable "previous active task";
  • never require another irreversible context switch merely to inspect a candidate.