Post-merge ChatGPT/Codex app regression: context usage donut missing again

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30693
• #30728

Powered by Codex Action

Additional clarification after reviewing the complete #23794 history and the duplicate bot's suggestions.

Why #30693 and #30728 are related but not the same release regression

Both suggested duplicates were filed on June 30 against the pre-merge 26.623 app. This issue reproduces after the separate July ChatGPT/Codex product merge on Windows 26.707. The older issues are valuable evidence that this feature was already fragile, but they do not cover whether the merge preserved the restored UI and preference. Please do not close this solely as a duplicate without testing the 26.623 → 26.707/post-merge upgrade path.

What was publicly proposed and what ultimately shipped

The historical sequence is important:

1. On May 22, @alexi-openai announced an updated /status command that would add the context meter to the thread-detail panel and suggested that additional status information might appear there. They then clarified that /status would be a persisted setting for all threads until toggled again.
2. @etraut-openai described the proposed right-side panel as passive and always visible at normal window widths, with /status acting as a persistent toggle across restarts.
3. After further feedback, @etraut-openai announced a changed resolution: restore the donut beneath the composer, with a persisted /status toggle.
4. When the release arrived, @etraut-openai clarified that the toggle had actually been implemented in Settings rather than through /status.

That record suggests the upper-right panel proposal was superseded by the decision to restore the compact composer donut; it should not be treated as a still-promised second feature without confirmation. However, the post-merge app now appears to preserve neither the expected composer indicator nor a working migration of the restored preference.

Could the current app owners please answer explicitly:

• Was the compact composer donut intentionally removed from the merged app, or is this an upgrade regression?
• Does the merged app migrate the pre-merge show-context-window-usage preference? If not, why not?
• Does the Settings toggle still exist in the merged experience, and where?
• Was the persistent upper-right /status panel intentionally abandoned when the composer donut was restored, or is some part of that design still expected to ship?
• Which automated test covers preservation of this behavior and preference across the product merge?

@alexi-openai @etraut-openai, you are the two publicly identifiable staff participants tied directly to the original proposal and resolution. Please route this to the current merged-desktop owner and help prevent it from being silently treated as an old 26.623 duplicate.

The immediate ask remains restoration of the compact passive indicator and its saved preference. The design-history question is secondary, but it needs a clear answer because the original thread contains multiple proposals and the post-merge app currently exposes none of the expected persistent context UI.

Leadership escalation request: recurring UI regressions without discoverable ownership

@tibo-openai @ae-openai @etraut-openai @alexi-openai @ambrosino-oai @efrazer-oai @richardopenai @aibrahim-oai @willwang-openai — I am asking for leadership-level routing and visible ownership here, not for each of you to personally debug these issues.

This expanded notification is intentional but scoped. It includes publicly identified Codex/product leadership; the staff tied directly to the original context-indicator decision; additional staff with public desktop-app triage activity; and staff who have handled the model-access/error-message and usage-reporting concerns referenced below. I could not identify a current public owner for the merged desktop UI, so I am asking this group to ensure the report reaches the correct accountable team.

@ambrosino-oai, public material identifies you as the product and engineering lead for the Codex app, and your GitHub profile identifies you with Codex at OpenAI. OpenAI's current hiring material also says the Codex App team owns the desktop application and IDE extension. You therefore appear to be the closest publicly identifiable owner between individual contributors and overall Codex leadership. Could you please take or assign ownership of the two post-merge regressions below and provide an initial disposition? If another person owns Projects/sidebar ordering or composer/status UI, naming or assigning that owner here would resolve the immediate ownership gap.

The immediate post-merge regressions are:

• This issue, #32104: an explicitly restored context-usage indicator disappeared again during the ChatGPT/Codex merge.
• #31836: all three visible project-ordering choices are ineffective after the merge; the same basic recent-project behavior was previously reported in #22487 and #23462.

I checked the public ownership and triage signals available in this repository. Neither current issue has an assignee. I could not find a desktop-UI CODEOWNERS entry or another publicly identifiable current UI owner. A closed-source frontend may naturally have ownership metadata elsewhere, but external reporters still need a visible path from a reproducible report to an accountable team.

This concern is based on a longer, measurable trail rather than these two reports alone. As of July 10, this account has authored 16 issues in openai/codex. All 16 remain open, and none currently contains a public comment from an OpenAI member/collaborator account. The oldest was filed on March 10. Community and automation activity exist on some reports, but there is no visible staff acknowledgement, disposition, or owner on any of the 16.

Relevant examples include:

• #14749 has been open since March 15 for a misleading plan/model availability error message. It followed staff acknowledgement elsewhere that the message was poor, yet repeated requests for ownership or a timeline received no staff response.
• #23462 documented project-ordering instability in May and remains open without staff acknowledgement. Closely related behavior has now returned in the merged app under #31836.
• #23794 was resolved only after extensive feedback and explicit staff commitments. The restored behavior then regressed again before or during the product merge, culminating in this issue.
• In #11189, OpenAI explicitly committed to clear downgrade notifications across all Codex surfaces, clearer UX, and smoother releases. A later question asking whether silent rerouting was actually fixed received no answer before the issue was eventually closed.

This does not establish intent, and I do not want to speculate that the absence of public ownership is deliberate. The observable outcome is nevertheless a systematic product and triage problem: ordinary, highly visible UI behavior regresses; older reports remain unacknowledged; related fixes are not protected across upgrades; and reporters cannot tell whether an issue is owned, rejected, planned, or simply unseen.

Please provide or route the following:

1. A named owner or accountable team for #32104 and #31836, with a visible acknowledgement and initial disposition.
2. Confirmation of whether these post-merge regressions are being considered for an urgent fix, plus an ETA when one is available.
3. Public component/ownership labels or a documented triage path for the desktop UI, even if the UI source and internal CODEOWNERS remain private.
4. Release-gating upgrade tests on Windows and macOS that preserve user settings and previously fixed workflow behavior across app merges and authentication transitions.
5. A product rule that model routing, speed-tier changes, quota-affecting defaults, and feature removals are never silent: the effective behavior should be clearly labeled and material changes should require confirmation or at least an unavoidable notification.
6. An audit of the merged app against previously closed high-impact UI regressions, rather than waiting for users to rediscover them after rollout.

The concern is not that every issue must be fixed immediately. The concern is that a production tool promoted for serious professional and enterprise workflows currently has no visible, reliable loop from issue report to ownership, communication, regression coverage, and release validation. Given the recurrence and the major product merge, that process gap now deserves urgent leadership attention.

Correction and implementation-level refinement

I want to remove a remaining ambiguity in the history above and narrow the post-merge regression claim accordingly.

The screenshot attached to @etraut-openai's May 29 clarification explicitly shows a Composer footer setting named Show context window usage, described as Show context window usage in the composer footer. Therefore, the Settings toggle mentioned in that comment controlled the restored composer donut, not the earlier proposed right-side thread-detail panel.

The resulting sequence is:

1. The May 22 proposal placed persistent status/context information in an always-visible right-side thread-detail panel, toggled globally through /status.
2. The May 28 decision superseded that placement and restored the donut beneath the composer.
3. The implementation that then shipped in the pre-merge Codex app exposed the donut through Settings rather than /status.

I found no evidence that the proposed persistent right-side /status panel shipped generally. The current app's Toggle pinned summary panel is a separate task-summary surface and should not be treated as that proposal.

The merged Windows 26.707 bundle still contains the application preference showContextWindowUsage, stored under show-context-window-usage, with a default of false. It also contains the visible route Settings → General → Composer → Show context window usage. In contrast, the current /status command opens a transient composer dialog for task ID, context usage, and rate limits; it is not the persisted toggle described in the early proposal.

This refines the regression claim:

• If enabling the Settings toggle restores the donut, the feature itself was not removed. The post-merge problem is that an already-enabled pre-merge preference may not have been migrated or was silently reset to its default, combined with poor discoverability.
• If the toggle is absent for a rollout/account, or the donut remains absent while it is enabled, that is a separate rendering or availability regression.

Could the current desktop owner confirm whether the 26.623 → 26.707 migration was intended to preserve show-context-window-usage, and whether an upgrade test covers that preference? This is now the central technical question for the context-indicator portion of this report.

I will not read that AI-generated slop book here, but buddy, you can simply toggle on the frickin donut again in the settings of the app.

Close this issue (it's just a settings flag)