openai / openai/codex

[Windows][Desktop 26.831.21537] Sidebar task rows lose overflow/right-click menu when Everyday/work mode is unavailable (API-key auth config)

Open
#42,276 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app auth bug windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

Environmental snapshot: Windows 11 build 26200; MSIX OpenAI.Codex 26.831.2377.0; embedded App 26.831.21537; bundled app-server/CLI 0.152.1; ~/.codex has no auth.json/auth.toml; config.toml has preferred_auth_method = "apikey" with a custom provider. The same symptoms persisted after a full app restart and after switching the conversation to Everyday mode.

Repro
  1. Open any local Codex task row in the left sidebar (both the pinned section and the projects section).
  2. Hover: only "Pin chat" and "Archive chat" buttons appear; no "..." overflow button.
  3. Right-click the row: no context menu shows at all (previously it contained Rename chat / Archive chat / Copy working directory / Copy deeplink, etc.).
  4. Switch the conversation to Everyday mode, create a new conversation, then repeat: exactly the same — no overflow/right-click menu.
  5. Control: the thread-header "..." menu (rename/archive/copy) works normally in both Everyday and Codex mode.
Expected vs Actual

Expected: same overflow menu and right-click context menu on sidebar rows as before the 26.831 update, or at least an explicit hint when those actions are unavailable.

Actual: silent disappearance of both entry points for all sidebar task rows.

Root-cause observations (from app.asar of 26.831.21537)
  • Sidebar task rows gate their overflow menu and native right-click menu on the same condition: getMenuItems: H ? menuBuilder : undefined, where H = (mode) === 'work' (sidebar task row component / renderActions).
  • The mode is derived from the conversation detail level: 'work' only while detail is STEPS_PROSE (Everyday); otherwise 'codex'.
  • The detail level has a hard override: if the workCloud permission is denied with reason unsupported-auth, the selector returns STEPS_COMMANDS unconditionally (lO selector). The permission builder marks workCloud as denied/unsupported-auth for non-chatgpt auth, which is consistent with this machine (API-key, no OAuth files in ~/.codex).
  • Secondary path: switching to Everyday writes the detail setting through remote config with optimistic: false and rolls back on failure, which could also keep detail at STEPS_COMMANDS.
Isolation / evidence
  • The thread-header "..." (same app, same session) is not gated by this mode check and works — so this is a row-level gate, not a broken command/menu system.
  • All sidebar rows (pinned and project sections) behave identically, so it is not specific to one thread.
  • If the local permission ED were unavailable, the detail selector would return STEPS_PROSE and the menu would show; menus are absent, so ED is allowed and the failure is in the workCloud/detail path above.
Related, not duplicates
  • #29156 (custom providers unusable on desktop) and #37718 (custom-provider sessions expose only some tools) — broader custom-provider gaps, different mechanisms.
  • #42265 ([macOS] unable to archive any conversation) — different platform and symptom.
  • #42191 ([Windows] ChatGPT/Codex selector unclickable on New Chat) — different symptom.
Notes / boundaries
  • No pre-update app.asar was available for a byte-level diff, so "regression" is based on the user-observed pre-26.831 behavior rather than a diff.
  • The UI-side authMethod could not be observed directly (the Chromium profile is locked at runtime and cookie values were not read); the "non-chatgpt auth" conclusion is inferred from the API-key environment above. If authMethod is chatgpt in your repro, please check the secondary remote-settings writeback path instead.
Request

Please confirm whether non-ChatGPT auth is intentionally restricted to a reduced sidebar row action set in 26.831 (then I can treat this as a UX/feedback item), or whether this is a regression that should restore parity. A workaround exists today: the thread-header "..." menu exposes rename/archive/copy actions.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the sidebar task-row component, its renderActions path, and the getMenuItems gate described in the issue; then trace the lO detail selector and workCloud permission handling. Reproduce with API-key authentication and compare the sidebar row menus with the working thread-header menu. Done means confirming whether the restriction is intentional or restoring sidebar action parity, with coverage for the affected auth and mode paths.

Written by the indexing model from the issue text.

Assessment

Domain
authentication, desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.