Feature request: hide or disable individual managed Codex accounts

[ne0lines]

Problem

I have multiple OpenAI/Codex accounts configured in CodexBar. Sometimes I want to keep an account’s credentials saved for later, but remove it from the account switcher, menu cards, Overview, widgets, and automatic refreshes.

At the moment, I can disable the entire Codex provider or remove an account, but neither option works for this case:

• Disabling Codex hides every Codex account.
• Removing an account discards its managed setup and makes it inconvenient to restore.
• Visible usage items only hides individual quota rows, not an account.

Requested behavior

Add an account-level Hide or Disable action for managed Codex accounts.

A disabled account should:

• remain stored locally, with its credentials intact;
• be excluded from the account switcher, menu cards, Overview, dashboard, widgets, --all-accounts, and background refreshes;
• not be selected or promoted automatically as the System Account;
• be restorable from Settings → Providers → Codex → Accounts, for example through a “Show disabled accounts” section.

The active System Account should not be possible to disable until another account is selected, or CodexBar should present a clear replacement flow.

Why this helps

This would let users temporarily declutter CodexBar or pause monitoring of a work/client/secondary subscription without deleting OAuth credentials or affecting their ordinary Codex CLI setup.

Related

• Add CLI commands to list and promote managed Codex accounts #3191 covers listing and promoting managed Codex accounts.
• Feature request: allow disabling refresh when switching Codex account tabs #3732 covers disabling the refresh triggered by switching account tabs.
• Improve Codex multi-account dashboard visibility #3552 improves visibility of multiple Codex accounts, but does not provide per-account visibility or enablement controls.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 22, 2026, 3:48 PM ET / 19:48 UTC.

Summary
Keep open for product sign-off: per-account disabling is absent from current main and remains distinct from the linked account-management work. Repository policy also prohibits automatic cleanup closure.

Reproducibility: not applicable. this requests a new account lifecycle; source inspection confirms that the existing model and Settings controls do not provide it.

Maintainer decision needed

Question	Recommendation
Should managed Codex accounts gain reversible disabling across monitoring and presentation, with disabling the live System Account blocked until an explicit replacement?	Approve reversible disabling: Keep existing accounts enabled by default and define shared eligibility, restoration, and externally changed System Account behavior before implementation.

Why: This adds a stored account lifecycle and changes selection eligibility; VISION.md requires sign-off, and the behavior when an external Codex login selects a disabled identity needs an explicit contract.

Next step
Obtain approval for the stored enablement contract and System Account reconciliation rules before scheduling this cross-surface feature.

Review details

Best possible solution:

If approved, persist a default-enabled account preference, enforce eligibility across consumers, retain credentials, and provide Settings restoration while requiring an explicit System Account replacement before disabling it.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this requests a new account lifecycle; source inspection confirms that the existing model and Settings controls do not provide it.

Is this the best way to solve the issue?

Yes, conditionally: a shared eligibility preference fits the existing projection architecture better than independent UI filters, but System Account reconciliation and stored-state compatibility need an approved contract.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 173afc88a417.

Label changes

Label changes:

• add P3: This is an optional account-management improvement with no reported broken existing workflow.
• add impact:ux-friction: Users cannot temporarily declutter or pause one managed account while preserving its saved setup.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is an optional account-management improvement with no reported broken existing workflow.
• impact:ux-friction: Users cannot temporarily declutter or pause one managed account while preserving its saved setup.

Evidence reviewed

What I checked:

• Current source identity and policy: Origin identifies steipete/CodexBar; HEAD matches fetched main at 173afc8. Read the full root AGENTS.md and applied its credential-isolation and shared-helper guidance. The supplied repository profile disallows automatic closure. (AGENTS.md:1, 173afc88a417)
• No persisted account disable state: ManagedCodexAccount stores identity, managed home, and authentication timestamps but no enablement or visibility preference. Its decoder likewise has no disabled-account state. (Sources/CodexBarCore/CodexManagedAccounts.swift:4, 173afc88a417)
• Shared enumeration includes stored accounts: The visible-account projection iterates all stored accounts, then reconciles the live system account and profile homes. CLI enumeration and app refresh consume this projection, so hiding only a Settings row would not implement the request. (Sources/CodexBarCore/Providers/Codex/CodexVisibleAccountProjection.swift:156, 173afc88a417)
• Removal is intentionally destructive: removeManagedAccount removes the saved record and deletes a validated managed home. The focused test explicitly expects both the account record and managed home to disappear; removal does not provide reversible disabling. (Tests/CodexBarTests/ManagedCodexAccountServiceTests.swift:695, 173afc88a417)
• Existing visibility setting has different semantics: Visible usage items controls quota, usage, and credit rows and explicitly does not change fetching, alerts, or quota calculations. (docs/ui.md:192, 173afc88a417)
• Latest release check: The v0.64.1 tag resolves to the supplied latest-release commit. Its managed-account model also lacks a disabled state; no shipped implementation of the requested lifecycle was established. (Sources/CodexBarCore/CodexManagedAccounts.swift:4, dd71934ffc30)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

The current managed-account model has no per-account monitoring/visibility flag. This should remain open. Filtering menu rows alone would leave refresh behavior unchanged and could remove the settings row needed to re-enable an account. The implementation needs a persistent preference that survives reauthentication and promotion, plus an unfiltered management list and a defined policy for the selected/System account.