[Windows][Desktop 26.831.21537] Sidebar task rows lose overflow/right-click menu when Everyday/work mode is unavailable (API-key auth config)
Nobody has claimed this yet.
- 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
- Open any local Codex task row in the left sidebar (both the pinned section and the projects section).
- Hover: only "Pin chat" and "Archive chat" buttons appear; no "..." overflow button.
- Right-click the row: no context menu shows at all (previously it contained Rename chat / Archive chat / Copy working directory / Copy deeplink, etc.).
- Switch the conversation to Everyday mode, create a new conversation, then repeat: exactly the same — no overflow/right-click menu.
- 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, whereH = (mode) === 'work'(sidebar task row component /renderActions). - The mode is derived from the conversation detail level:
'work'only while detail isSTEPS_PROSE(Everyday); otherwise'codex'. - The detail level has a hard override: if the workCloud permission is
deniedwith reasonunsupported-auth, the selector returnsSTEPS_COMMANDSunconditionally (lOselector). The permission builder marks workCloud asdenied/unsupported-authfor 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: falseand rolls back on failure, which could also keep detail atSTEPS_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
EDwere unavailable, the detail selector would returnSTEPS_PROSEand the menu would show; menus are absent, soEDis 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
chatgptin 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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