fix: harden Codex notification recovery

[steipete]

Summary

• harden Codex session-restored notifications against transient, stale, expired, windowless, and cross-account quota observations
• preserve the trusted depleted reset boundary while requiring ordered confirmation for ambiguous post-reset recovery
• fail closed across credential/source rotation and provider cleanup, while preserving legitimate recovered depletion alerts
• consolidate and expand the reducer regression suite

Post-merge hardening follow-up to #2060. Preserves contributor credit from @Yuxin-Qiao.

Proof

• focused Codex reducer suite: 34/34 passed
• combined Codex reducer + Claude synthetic-placeholder integration: 70/70 passed
• make check: SwiftFormat and SwiftLint clean
• CODEXBAR_TEST_RETRY_NON_TIMEOUT_FAILURES=0 make test: 612/612 tests, 51/51 shards, zero retries/recoveries/timeouts
• autoreview: clean, no accepted/actionable findings
• Developer ID-signed debug app from exact head 60f069aafe9bca30fe225f4e1996f15470d12664 passed strict codesign and Gatekeeper validation
• isolated live fixture: baseline, depletion, pre-boundary transient recovery suppression, repeated depletion, first post-boundary confirmation, restored notification, and positive hold all passed
• source-blind live contract: all seven phases passed; exactly one depleted and one restored enqueue/post, no duplicate restored/depleted event, stable synthetic owner resolved
• request proof: two bounded warmup requests plus exactly two authenticated loopback usage requests per explicit refresh (16 total), with no unexpected fixture paths
• live isolation: loopback-only synthetic OAuth, no unexpected child process, no external connection, no SecurityAgent, production app PID/identity unchanged, protected debug preferences restored and verified

Risk

Medium. This rewrites the notification transition reducer and its caller state, but only affects notification decisions; provider fetching and displayed usage snapshots remain unchanged. Regression coverage includes non-Codex behavior, observation ordering, missing reset metadata, stale/post-reset samples, disabled/unavailable cleanup, and identity rotation.

Dependencies

No dependency changes; freshness review not applicable.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 11, 2026, 6:58 PM ET / 22:58 UTC.

Summary
The PR replaces scalar quota tracking with an owner-aware temporal reducer for Codex notification recovery and expands regression coverage across account, reset-boundary, cleanup, and observation-ordering edge cases.

Reproducibility: yes. The exact-head isolated fixture exercises depletion and ambiguous recovery and observes exactly one depleted and one restored notification.

Review metrics: 3 noteworthy metrics.

• Changed surface: 10 files, +1299/-350. The branch substantially rewrites notification transition state and its focused regression suite.
• Focused live contract: 7 phases, 2 notification posts. The reported fixture observes exactly one depleted and one restored event throughout the recovery sequence.
• Reported validation: 34 focused, 70 combined, 612 full tests. Validation spans the reducer, adjacent Claude placeholder behavior, and the complete sharded suite.

Root-cause cluster
Relationship: same_root_cause
Canonical: #2060
Summary: This PR hardens the same Codex false-restored-notification root cause addressed by the merged precursor.

Members:

• canonical: fix(codex): suppress false session restore when resetsAt is unchanged #2060 - The merged precursor introduced the initial unchanged-reset false-restore suppression that this branch broadens and hardens.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• none.

Risk before merge

• [P1] Ambiguous legitimate recoveries intentionally wait for a second ordered positive sample, reducing false alerts but potentially delaying a real restored notification by one refresh.
• [P1] The current Linux x64 failure could not yet be classified because the overall workflow remained in progress and its job log was unavailable; required checks should settle before merge.

Maintainer options:

1. Accept confirmed recovery semantics (recommended)
   Merge after required checks settle, accepting a one-refresh delay for ambiguous restores in exchange for preventing false, duplicate, and cross-account notifications.
2. Pause for a different latency policy
   Hold the PR if restored-notification immediacy should outweigh the demonstrated false-positive protection.

Next step before merge

• No automated repair is identified; required checks should settle and the repository owner can then make the ordinary merge decision.

Security
Cleared: No concrete security or supply-chain concern was found; identity inputs are normalized and hashed locally, with no dependency, workflow, permission, secret-access, or external execution changes.

Review details

Best possible solution:

Keep the centralized owner-aware reducer, including its freshness barrier and confirmation state, with the focused regression suite and isolated live fixture serving as the behavioral contract for future notification changes.

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

Yes. The exact-head isolated fixture exercises depletion and ambiguous recovery and observes exactly one depleted and one restored notification.

Is this the best way to solve the issue?

Yes. A typed reducer with explicit ownership, observation freshness, trusted reset boundaries, and confirmation state is the narrowest maintainable way to keep every refresh and cleanup path consistent.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 50d790360a09.

Label changes

Label changes:

• remove proof: sufficient: Current real behavior proof status is not_applicable, not sufficient.

Label justifications:

• P2: The PR fixes misleading Codex notifications through a provider-specific behavior change with limited blast radius.
• merge-risk: 🚨 message-delivery: The changed reducer directly determines whether depleted and restored OS notifications are posted, suppressed, or delayed.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The mandatory external-contributor proof gate does not apply to this owner-authored PR, though its exact-head signed-app and isolated live fixture evidence is strong.

Evidence reviewed

What I checked:

• Temporal recovery reducer: Before a trusted depleted boundary passes, positive observations remain suppressed; afterward an advanced valid boundary restores immediately, while ambiguous metadata requires two ordered positive observations. (Sources/CodexBar/SessionQuotaNotifications.swift:218, 60f069aafe9b)
• Owner isolation: Codex notification ownership derives from normalized provider identity or email, source, and credential fingerprint; unresolved or ambiguous identities fail closed. (Sources/CodexBar/Providers/Codex/CodexLimitResetOwnerKey.swift:21, 60f069aafe9b)
• Publication wiring: Both general Codex refresh publication and token-account publication pass the derived owner key into session-quota transition handling. (Sources/CodexBar/UsageStore+Refresh.swift:431, 60f069aafe9b)
• Cleanup watermark: Codex invalidation removes transition state and retains the latest observation timestamp as a freshness barrier, preventing stale cached samples from becoming a new baseline or duplicate depletion. (Sources/CodexBar/SessionQuotaNotifications.swift:439, 60f069aafe9b)
• Regression matrix: The exact head contains 34 focused tests covering future, expired, missing, and regressed boundaries; stale ordering; owner and source changes; cleanup; disabled notifications; windowless samples; and credential rotation. (Tests/CodexBarTests/CodexSessionQuotaFalseRestoreTests.swift:11, 60f069aafe9b)
• Real behavior proof: The PR body reports exact-head signed-app validation and an isolated seven-phase loopback contract with exactly one depleted and one restored notification, bounded requests, and no external or Keychain access. (60f069aafe9b)

Likely related people:

• steipete: Authored the owner-aware hardening series, integrated it across refresh and cleanup paths, and is the repository owner. (role: feature owner; confidence: high; commits: 15bf79a7889f, e5c9adf7c721, 5e1a6c82d7ce; files: Sources/CodexBar/SessionQuotaNotifications.swift, Sources/CodexBar/UsageStore.swift, Sources/CodexBar/Providers/Codex/CodexLimitResetOwnerKey.swift)
• Yuxin-Qiao: Authored the merged precursor for unchanged-reset false restores and is credited as co-author on the principal hardening commits. (role: introduced behavior; confidence: high; commits: 72acff1cda35, 15bf79a7889f, 8b4480a49691; files: Sources/CodexBar/SessionQuotaNotifications.swift, Tests/CodexBarTests/CodexSessionQuotaFalseRestoreTests.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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.

Review history (3 earlier review cycles)

• reviewed 2026-07-11T22:14:51.501Z sha eed68c9 :: needs maintainer review before merge. :: none
• reviewed 2026-07-11T22:28:40.795Z sha 6ce37f2 :: needs maintainer review before merge. :: none
• reviewed 2026-07-11T22:52:12.248Z sha 60f069a :: needs maintainer review before merge. :: none

[steipete]

Maintainer validation complete on exact head 60f069a.

• 34 Codex session quota false-restore tests passed
• 6 Claude synthetic-placeholder notification tests passed
• make check passed
• full signed bundle loop passed all 612 selections across 51 groups with zero failures, retries, or timeouts
• Developer ID signature and Gatekeeper validation passed
• real Codex OAuth usage resolved successfully with Keychain UI disabled
• 8 consecutive bounded refreshes stayed stable; no restore notification wording, crash, fatal, or hang logs; app process remained alive
• source-blind behavior validation passed at 0.94 confidence
• autoreview returned no actionable findings
• exact-head CI is green; the first Linux-x64 run hit unrelated parallel-test flakiness and its failed-job rerun passed in 7m19s