Add Notion AI provider

[n0ah37]

Summary

Adds a Notion AI provider that tracks the two usage-allowance windows Notion shows in Settings → Notion AI → Usage:

• Rolling — the 6-hour window, with its reset countdown
• Monthly — the billing-period window, with its period end

Both bars carry an expected-usage estimate (n% in deficit / n% in reserve), on the card and in the CLI.

Notion starts enforcing this allowance on August 3, 2026. Before that date the same endpoint already returns real usage numbers with "enforcement": "preview", so the gauges are accurate either way — which is why it seemed worth having in the menu bar now rather than after people start hitting the cap.

No existing issue or PR covers Notion, so this is a fresh integration rather than a follow-on.

Rebased onto current main after #2606 ("derive provider registrations from descriptors"). Notion now registers through ProviderManifest and ProviderImplementationManifest, its icon style is .init(provider: .notion), and the "not yet supported in widgets" behavior that used to live in a hand-written switch is expressed as widgetSelectable: false on the descriptor.

Data source

Two cookie-authenticated POSTs to app.notion.com per refresh, both endpoints the Notion web app itself calls:

Endpoint	Purpose
/api/v3/getSpaces	Resolves the signed-in account (email, name) and its workspaces, including plan_type and subscription_tier. Drives automatic workspace selection and the identity line.
/api/v3/getCreditRateLimitStatus	The allowance itself, for one spaceId.

{
  "status": "within_limit",
  "window": { "creditType": "basic_ai_credits", "scope": "per_user", "window": "6h", "used": 42.5, "limit": 100 },
  "resetsInSeconds": 12600,
  "billingPeriodWindow": {
    "creditType": "basic_ai_credits", "scope": "per_user", "cadence": "billing_period",
    "used": 18.0, "limit": 100, "periodEndMs": 1788000000000
  },
  "enforcement": "preview"
}

(Illustrative values — the shape is what was observed.)

window → primary (window length parsed from the 6h token, reset from resetsInSeconds), billingPeriodWindow → secondary (reset from periodEndMs). Usage is scaled against the returned limit rather than assumed to be a percentage, so a future non-100 limit keeps working.

Behaviour notes

• Plan gating. Only Business and Enterprise workspaces carry an allowance. Anything else answers {"status":"not_applicable"}, which surfaces as a clear provider error naming the workspace instead of a 0% gauge.
• No window is better than a fabricated one. Every field in the response is optional, so an unrelated 200 body decodes cleanly into an all-nil status. The parser rejects a payload carrying neither window, and a window with no usable limit is omitted rather than reported as 0% — a false "plenty of headroom" is the worst thing this provider could show.
• Multi-workspace accounts. Defaults to the first workspace on a plan that has an allowance. A specific one can be pinned via the Workspace ID settings field or the existing workspaceID provider config field (no config-schema change) — both dashed and undashed UUID forms are accepted. An id the account cannot see falls back to auto-selection rather than being queried for an opaque 403.
• The imported header is persisted through CookieHeaderCache, which is what makes background refreshes work at all. BrowserCookieAccessGate.shouldAttempt refuses Chromium cookie reads unless the refresh is user-initiated, so a timer tick can never reach the browser store; without a cached header the provider failed on every automatic refresh and told the user to log in while their session was perfectly valid. A rejected cached header is cleared and re-imported, following the Abacus/Manus shape.
• A deferred import no longer reads as "logged out". When the gate suppresses every candidate browser but profile data exists on disk, the provider reports that cookies can only be read during a manual refresh, rather than telling the user to log in to an account they are already logged in to.
• Cookie import requires token_v2, and de-duplicates by cookie name across the Notion domains — a stale token_v2 left on the legacy notion.so alongside the live one would otherwise put two of them in a single header. This is not hypothetical: it reproduced on the machine this was developed on, which held token_v2 on both .app.notion.com and .www.notion.so. Imports are also cached for 5s like the other cookie providers, so a refresh tick does not re-read Safe Storage every time.
• cURL captures do not forward x-notion-space-id. A capture taken in one workspace would pin that space while the request body asks for the configured one, and the mismatch would surface as another workspace's usage rather than an error.
• Not read: Notion credits (Custom Agents, Workers) are a separate meter on getAIUsageEligibilityV2. Out of scope here.
• Follows Perplexity's shape throughout — descriptor + single web strategy, fetcher, snapshot mapping, settings store, cookie-source picker with Off, manual Cookie header / cURL capture path, and a login action. Declares widgetSelectable: false, so it stays out of the widget picker.

Pace

Notion reports only periodEndMs for the billing period, so the snapshot carries the shared monthly sentinel — which is what makes the descriptor's .calendarMonthResetWindow match — and pace resolution substitutes the real calendar month ending at the reset. A flat 30 days would misstate expected usage in February and in every 31-day cycle.

Three paths scored these windows without resolving first, so fixing only the descriptor would not have been enough:

• UsageStore.weeklyPace — feeds the menu-bar pace token, the "runs out" text, and predictive pace warnings.
• resetWindowPaceDetail — preferred a caller-supplied pace measured against the raw window, silently undoing the resolution computed one line above it.

Both now resolve, which also fixes the same latent bug for the eight other providers carrying that sentinel (Amp, MiMo, StepFun, Doubao, Alibaba ×2, OpenCode Go): before this, a 31-day cycle exceeded the 30-day sentinel outright and dropped its pace token for the first day of every long month.

Two smaller pieces come with it:

• The rolling window is paced as a session window in the CLI too. Its 6-hour length sat outside the CLI's 300-minute session ceiling, so the card and codexbar usage disagreed about whether that bar had an estimate at all.
• codexbar now honors the Notion settings snapshot. Workspace ID, the manual cookie header, and the off source previously had no effect on the CLI, which always auto-selected a workspace.
• A rolling length that parses to exactly the monthly sentinel (30d, 720h, 43200m) is dropped rather than reported, since pace matching keys on that number and would otherwise resolve the rolling bar as a calendar cycle ending hours away.

One change outside the provider

UsageStore.debugLogText gained a .notion case (the debug pane previously said "not yet implemented" while a working probe existed). That tipped the enclosing function to cyclomatic complexity 21, so .openai and .azureopenai — which already call the same apiKeyDebugLine helper — are folded into one case. Happy to drop the debug-log wiring instead if you'd rather that switch stayed untouched.

Provider count

Bumped 66 → 67 in the places Scripts/check-site-locales.mjs enforces: README.md, docs/providers.md, docs/social.html, docs/llms.txt, docs/index.html, and the three counted keys across all 23 locales in docs/site-locales.mjs.

CodexParserHash.generated.swift is not touched. It was, until #2606 replaced the exhaustive provider switch in CostUsageScanner.swift with a default: arm — the rebase dropped that regeneration along with the case.

Docs

• docs/notion.md — setup, data source, mapping table, troubleshooting.
• docs/providers.md — strategy-table row and provider section.
• docs/configuration.md — notes Notion as a workspaceID consumer.

Commands run

swift build
make check                                    # SwiftFormat + SwiftLint, 0 violations
make test                                     # full sharded suite

Verification

The endpoints, payload shape, and mapping were verified against a live Business workspace — the API's rolling and billing figures matched what the Notion settings pane rendered, including the reset countdown and period end. getSpaces plan gating was confirmed by calling the endpoint for both a Business and a free personal space; the latter returns not_applicable, and an unknown space id returns 403.

31 unit tests cover parsing (both the singly- and doubly-wrapped record shapes), window mapping, workspace selection and id normalization, session-file permissions and round-trip, the resolved calendar-cycle length against known 28- and 31-day resets, the sentinel collision on the rolling token, and — through a stubbed ProviderHTTPTransport — the 401, non-200, and not_applicable paths. NotionMenuCardModelTests drives real menu-card model construction and asserts the monthly bar's estimate is unchanged whether or not a precomputed pace is supplied; without the resolution fix it reports 10% in deficit instead of 15%.

Redacted live proof from this head is in a comment below — manual import, then a background refresh that shows Cookie cache miss yet still succeeds from the persisted token_v2, which is the CredentialFileWriter fallback this PR adds rather than the pre-existing cookie cache. The session file is -rw-------. The Monthly pace line in that output also shows the calendar-cycle fix end to end.

No menu screenshots are included.

Known gap — the Notion desktop app

This reads a browser session only. Notion.app is Electron and does keep a Chromium cookie store, but SweetCookieKit's Browser is a closed enum and its decryption keys come from a per-browser catalogue of Safe Storage labels; Notion.app's key ("Notion Safe Storage") is not in it, so a store pointed at that directory would be found and not decrypted. Supporting it is a SweetCookieKit change — happy to open that separately if you'd take it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8c59645cfe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 3, 2026, 6:37 AM ET / 10:37 UTC.

ClawSweeper review

What this changes

Adds a default-disabled Notion AI provider that imports or accepts a Notion session, selects an eligible workspace, shows rolling and billing-period allowance usage in the menu and CLI, and documents the setup.

Merge readiness

⚠️ Ready for maintainer review - 4 items remain

Keep open for maintainer merge review. The branch adds a coherent default-disabled provider, fixes the two prior cookie-handling findings, and includes redacted after-fix terminal proof; the remaining judgment is whether CodexBar should accept the unsupported Notion cookie/API boundary after one owner-run comparison against a Business workspace.

Priority: P2
Reviewed head: dfac3f71826235190de3464bd29ab9ce98a95b9c
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A substantial, coherent provider addition with strong live terminal proof and focused coverage; the remaining merge gate is owner acceptance of the external cookie/API boundary.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): The current-head comment provides redacted terminal proof of a real Notion Business workspace: manual browser import, successful later background refresh from the persisted session after a cache miss, live allowance output, and 0600 file permissions.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The current-head comment provides redacted terminal proof of a real Notion Business workspace: manual browser import, successful later background refresh from the persisted session after a cache miss, live allowance output, and 0600 file permissions.
Evidence reviewed	6 items	Provider registration follows current architecture: The Notion descriptor and implementation are added to the manifest-based registration points introduced on current main, rather than restoring the former parallel switches. Cookie boundary is deliberately constrained: The proposed descriptor sets Chrome-only automatic import, and the fetcher sends the imported or manual session only to the fixed app.notion.com base URL; its captured-header allowlist intentionally excludes the workspace-pinning header. Persisted fallback is owner-only and atomic: The proposed session store persists only token_v2 through the existing credential writer; that writer creates a 0600 staged file before writing, syncs it, and atomically renames it into place. The PR adds permission and round-trip tests.
Findings	None	None.
Security	None	None.

How this fits together

CodexBar provider descriptors register the supported usage sources, while provider implementations turn settings and credentials into usage snapshots for the menu bar and CLI. This change adds Notion's browser-session web flow, maps its workspace allowance responses into the shared rate-window model, and feeds the existing pace and display surfaces.

flowchart LR
    A[Notion browser session] --> B[Chrome-only cookie import or manual header]
    B --> C[Notion provider fetcher]
    C --> D[Workspace and allowance endpoints]
    D --> E[Usage snapshot]
    E --> F[Pace calculation]
    F --> G[Menu bar and CLI output]

Loading

Decision needed

Question	Recommendation
After a live Business-workspace comparison, should CodexBar accept the supported scope of a Chrome-only Notion session import plus an owner-only persisted token for background refreshes despite Notion’s unsupported internal API contract?	Verify and accept the boundary: Perform the stated owner-run comparison and merge if the values and background session reuse match, accepting that endpoint changes may require future maintenance.

Why: The implementation is coherent and proof-positive, but accepting a third-party browser-session credential and unsupported endpoint as a supported provider is a product and credential-boundary choice that cannot be resolved from tests alone.

Before merge

• Resolve merge risk (P1) - This adds a new cookie-authenticated integration against unsupported internal Notion endpoints, so a Notion-side contract or session-policy change can stop refreshes without a CodexBar code change.
• Resolve merge risk (P1) - The feature persists a reusable Notion session token in an owner-only local credential file to support non-interactive refreshes; maintainers must explicitly accept that credential-storage boundary before release.
• Complete next step (P2) - No mechanical repair remains; the next action is the owner-run live verification and explicit acceptance of the Notion session-storage and unsupported-endpoint boundary before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Change surface	37 files affected; +2,120 / -91 lines	The new provider spans core parsing, credential flow, app settings, CLI rendering, documentation, and focused tests, so the owner-run verification should cover the complete user path.

Merge-risk options

Maintainer options:

1. Verify the live integration, then accept the scoped risk (recommended)
   Compare both allowances with Notion’s Business-workspace UI and confirm a non-user-initiated refresh reuses the stored session before merging this default-disabled integration.
2. Pause for a different credential policy
   Do not merge if owner-only file storage for a reusable Notion session is outside the repository’s acceptable credential boundary.

Technical review

Best possible solution:

Land the provider only after an owner verifies that a Business workspace's Rolling and Monthly values match Notion’s usage page and confirms a later background refresh succeeds without another browser import, while retaining the Chrome-only and owner-only storage constraints.

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

Not applicable as a bug report. The contributor supplied redacted after-fix terminal output from a real Business workspace, including manual import, non-interactive reuse after a cookie-cache miss, and owner-only session-file permissions.

Is this the best way to solve the issue?

Yes, conditionally. The descriptor/manifest integration follows current main and preserves existing cookie-source conventions, but a maintainer must still approve the unsupported Notion API and persisted-session boundary after a live comparison.

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: This is a bounded new provider integration with real user value, but it is default-disabled and has no demonstrated urgent regression.
• merge-risk: 🚨 security-boundary: Merging expands CodexBar’s credential boundary to import and persist a reusable Notion browser-session token for an unsupported web API.
• 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. Sufficient (terminal): The current-head comment provides redacted terminal proof of a real Notion Business workspace: manual browser import, successful later background refresh from the persisted session after a cache miss, live allowance output, and 0600 file permissions.
• proof: sufficient: Contributor real behavior proof is sufficient. The current-head comment provides redacted terminal proof of a real Notion Business workspace: manual browser import, successful later background refresh from the persisted session after a cache miss, live allowance output, and 0600 file permissions.

Evidence

What I checked:

• Provider registration follows current architecture: The Notion descriptor and implementation are added to the manifest-based registration points introduced on current main, rather than restoring the former parallel switches. (Sources/CodexBarCore/Providers/ProviderManifest.swift:74, a557d0229f90)
• Cookie boundary is deliberately constrained: The proposed descriptor sets Chrome-only automatic import, and the fetcher sends the imported or manual session only to the fixed app.notion.com base URL; its captured-header allowlist intentionally excludes the workspace-pinning header. (Sources/CodexBarCore/Providers/Notion/NotionProviderDescriptor.swift:29, dfac3f718262)
• Persisted fallback is owner-only and atomic: The proposed session store persists only token_v2 through the existing credential writer; that writer creates a 0600 staged file before writing, syncs it, and atomically renames it into place. The PR adds permission and round-trip tests. (Sources/CodexBarCore/Providers/Notion/NotionSessionStore.swift:43, dfac3f718262)
• Prior review findings are fixed at the reviewed head: The earlier Chrome-only import and bare-token normalization findings are addressed by the current descriptor/import path and request-context normalization; no remaining line-level defect was identified in this re-review. (Sources/CodexBarCore/Providers/Notion/NotionUsageFetcher.swift:170, dfac3f718262)
• After-fix behavior proof is present: The contributor's August 3, 2026 terminal transcript shows a user-initiated cookie import followed by a background CLI refresh that succeeds after a shared cookie-cache miss using the persisted session, plus a 0600 session-file mode check. (dfac3f718262)
• Current release does not contain this feature: Current main is at eddf0b4 and CHANGELOG.md identifies 0.46.1 as unreleased and v0.46.0 as the latest shipped release; this open branch is not a current-main implementation to close as already released. (CHANGELOG.md:3, eddf0b4a1809)

Likely related people:

• Peter Steinberger: Introduced the manifest-based provider registration architecture on current main and directly engaged on this PR's rebase and final live-verification gate. (role: recent provider-platform contributor; confidence: high; commits: a557d0229f90; files: Sources/CodexBarCore/Providers/ProviderManifest.swift, Sources/CodexBar/Providers/Shared/ProviderImplementationManifest.swift)
• Petr Kratochvíl: Recent history connects this contributor to menu-bar pace behavior that the PR extends and corrects for calendar-backed allowance windows. (role: recent pace-surface contributor; confidence: medium; commits: f93e3ed460ad, 26ce38d416ff; files: Sources/CodexBar/UsageStore+HistoricalPace.swift, Sources/CodexBar/MenuCardView+ModelHelpers.swift, Sources/CodexBarCLI/CLIRenderer.swift)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Have an owner compare Rolling and Monthly values against Notion’s usage page and verify a later background refresh on the freshly built bundle.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• 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.

History

Review history (6 earlier review cycles)

• reviewed 2026-08-01T17:05:08.824Z sha 8c59645 :: needs real behavior proof before merge. :: [P1] Restrict automatic Notion cookie imports to Chrome | [P2] Prefix a pasted token with its cookie name
• reviewed 2026-08-01T20:12:39.680Z sha 8c59645 :: needs real behavior proof before merge. :: [P1] Restrict automatic Notion cookie imports to Chrome | [P2] Prefix a pasted token with its cookie name
• reviewed 2026-08-03T01:59:36.710Z sha 138f053 :: needs real behavior proof before merge. :: none
• reviewed 2026-08-03T02:10:25.727Z sha a7dc716 :: needs real behavior proof before merge. :: none
• reviewed 2026-08-03T10:22:43.401Z sha 6a7e61e :: needs real behavior proof before merge. :: none
• reviewed 2026-08-03T10:29:40.647Z sha dfac3f7 :: needs maintainer review before merge. :: none

[steipete]

Maintainer update pushed; this PR is not merged.

The branch is rebased onto current main (fd7857a065) and now includes:

• Chrome-only automatic cookie import by default, while preserving an explicit browser-order override in the importer.
• Correct normalization of a pasted bare token_v2 value to token_v2=<value>.
• A validated Notion session fallback that persists only token_v2 through CredentialFileWriter (atomic owner-only 0600 file), alongside the shared cookie cache.
• Explicit documentation that this relies on unsupported internal Notion /api/v3 endpoints that may change or break without notice.
• Fixture-backed parsing for getSpaces and getCreditRateLimitStatus, plus session-file permission/round-trip tests.
• The requested ### Added changelog entry thanking @n0ah37.

Proof on the pushed head a7dc7163f0:

• make check — passed (SwiftFormat, SwiftLint, docs/locales, generated parser hash, packaging checks).
• swift test --filter Notion — 24 tests passed across the Notion usage and session-store suites.
• make test — all 790 selections passed in 66/66 groups; zero retries and zero timeouts.
• Final branch autoreview against origin/main — clean, no accepted/actionable findings (Codex Sol, high reasoning, 0.99 confidence).

No live Notion request was made during this repair. Maintainer live verification is the final gate: Peter should enable Notion AI, explicitly refresh/import the Chrome session, confirm Rolling and Monthly values match Notion’s Settings → Notion AI → Usage page, then confirm a later background refresh reuses the persisted session without another browser import. Once that is checked, the provider is ready for maintainer merge review.

[n0ah37]

Rebased onto current main (a557d022) and added the pace/CLI work that belongs with this feature.

Rebase. #2606 ("derive provider registrations from descriptors") landed in between and rewrote the machinery this provider hooks into. Notion is now registered through ProviderManifest and ProviderImplementationManifest, its icon style is .init(provider: .notion), and it declares widgetSelectable: false to preserve the "not yet supported in widgets" behavior the old hand-written switch expressed. Nothing else about the provider changed.

New in this push. Both allowance bars now carry an expected-usage estimate:

• The billing-period window is scored against the real calendar month ending at its reset, not a flat 30 days. Notion reports only periodEndMs, so the snapshot carries the shared monthly sentinel and the descriptor declares .calendarMonthResetWindow; resolution substitutes the true cycle length. Three paths scored these windows without resolving first — UsageStore.weeklyPace (menu-bar pace token, "runs out" text, predictive pace warnings) and resetWindowPaceDetail when handed a precomputed pace — so a February cycle read 6% expected at 0% used, and a 31-day cycle lost its pace token for a day. Both now resolve, which fixes the same latent bug for the eight other providers carrying that sentinel (Amp, MiMo, StepFun, Doubao, Alibaba ×2, OpenCode Go).
• The rolling window is paced as a session window on the card and in the CLI; its 6-hour length previously fell outside the CLI's 300-minute session ceiling, so the two surfaces disagreed.
• codexbar now honors the Notion settings snapshot at all — Workspace ID, manual cookie header, and the off source had no effect on the CLI before.
• A rolling length that parses to exactly the monthly sentinel (30d, 720h, 43200m) is dropped, since it would otherwise be resolved as a calendar cycle ending hours from now.

Head: dfac3f71 · make check clean (0 violations, 1731 files) · make test 798 selections, 67/67 groups, 0 failures, 0 retries, 0 timeouts.

Real behavior proof

Captured on this head against a real Notion Business workspace. Account, workspace name, space id, and home path redacted; the allowance figures are live and matched Settings → Notion AI → Usage.

1. Manual import — user-initiated, the only context allowed to read a Chromium cookie store:

$ CodexBarCLI cookie refresh --provider notion --allow-keychain-prompt
notion: ✅ Browser cookie refreshed.

2. Later background refresh — codexbar usage runs outside .userInitiated, so it cannot reach the browser store at all:

$ CodexBarCLI usage --provider notion --verbose --log-level verbose
debug com.steipete.codexbar.cookie-cache: provider=notion   Cookie cache miss
debug com.steipete.codexbar.notion:      [notion] Using stored session from <browser> Default
debug com.steipete.codexbar.notion:      [notion] Cookie names: token_v2
debug com.steipete.codexbar.notion:      [notion] Using workspace <redacted> (<redacted>)
[notion] fetch strategies:
  - notion.web (web) available
== Notion AI (web) ==
Rolling: 62% left [=======-----]
Pace: 23% in deficit | Expected 16% used | Projected empty in 1h 31m
Resets in 5h 4m
Monthly: 60% left [=======-----]
Pace: On pace | Expected 41% used | Lasts until reset
Resets in 18d 9h
Account: <redacted>
Plan: Business

The first two log lines are the specific claim: the shared cookie cache missed, and the fetch still succeeded from the token_v2 persisted by NotionSessionStore — so this exercises the CredentialFileWriter fallback added in this PR rather than the pre-existing cookie cache. That branch is gated on ProviderInteractionContext.current != .userInitiated, so it is reachable only from a non-user-initiated refresh.

The Monthly pace line also demonstrates the calendar-cycle fix end to end: with the reset 18d 9h away in a 31-day billing cycle, Expected 41% used is 12.6/31. Scoring the same window against a flat 30 days would report 39%.

3. Persisted session is owner-only:

$ stat -f "%Sp  %z bytes  %N" ~/Library/Application\ Support/CodexBar/notion-session.json
-rw-------  603 bytes  /Users/<redacted>/Library/Application Support/CodexBar/notion-session.json

Both earlier Codex findings are present on this head: browserCookieOrder: ProviderBrowserCookieDefaults.chromeOnlyImportOrder (P1) and the bare-token_v2 normalization in requestContext(from:) (P2).

[n0ah37]

@clawsweeper re-review

Proof from the current head dfac3f71 is in the comment above, and the PR body now points at it. The branch is also rebased onto current main (past #2606), so the earlier conflict is gone.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Failed
• Detail: Durable publication exhausted its retry budget and was retained for operator dead-letter recovery.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/30807183007
• Updated: 2026-08-03T10:51:30.487Z