[WRONG BRANCH] release: promote verified 2.52.0-preview.20260911 product tree to preview

.github/pr-assets/codex-quota-evidence.md

@@ -0,0 +1,48 @@
+# Codex quota registration browser verification
+
+These captures show the production dashboard bundle served by `startServer`,
+using the real management routes, device-login implementation, credential store,
+account-pool controller, and refresh button. They are not component fixtures.
+
+The server used an isolated OpenCodex/Codex home. Only external provider responses
+were mocked: device authorization, token exchange, WHAM usage, and the completed
+inference stream. The account identity and credentials are synthetic. The empty
+native-main home explains the separate Main Account warning in both screenshots.
+No live OpenAI account was used or charged.
+
+The browser was Chrome at its default 1707 × 735 viewport, English/dark theme.
+Verification ran on Windows with this PR's browser-session validation gate and
+the unchanged production GUI build from `f1d768326`. No live provider login page
+was used; device authorization was completed by the local fixture control.
+
+1. Open Codex Set → Multi-auth, click Add, enter an account ID, and choose Device
+   code login. Authorize through the mock device service.
+2. The actual token exchange and authenticated usage read return a Pro account
+   with weekly usage at 100%. Registration persists it as validation pending:
+   one usage read, zero model calls, and no successful-validation timestamp.
+   The completion notice also says validation is pending; no model-selection
+   dialog opens for this unroutable account.
+3. Reload the page and click Refresh quotas while usage is still 100%.
+   The account remains pending. Cumulative counts: two usage reads, zero model
+   calls. The pending screenshot shows the status and the missing selection button.
+4. Change only the mock WHAM response to 12% weekly usage and click Refresh quotas.
+   The server receives a completed validation response. Cumulative counts:
+   three usage reads, one model call. The pending flag clears, the validation
+   timestamp is persisted, and “Use this account next” appears.
+5. Select the recovered account and confirm the dialog. The stored config reports
+   `weekly-demo` as the active account.
+
+Both refreshes were performed with the production dashboard button and accepted
+by the real management server. Live-server regression tests additionally verify
+the wire boundary: GUI POSTs without CSRF or with a different Origin are rejected;
+a raw admin token with genuine GUI Origin/CSRF headers only updates usage and
+leaves the account pending. Only the authenticated GUI session completes model
+validation. GET quota refreshes remain observational.
+
+| Capture | Weekly usage | Pending | Model calls so far |
+| --- | --- | --- | --- |
+| `codex-quota-pending.png` | 100% | Yes | 0 |
+| `codex-quota-recovered.png` | 12% | No | 1 |
+
+This verifies dashboard-to-server behavior against controlled upstream responses.
+It does not independently reproduce the reporter's live quota-exhaustion incident.

AGENTS.md

@@ -150,8 +150,8 @@ say where it is; do not add it to `devlog/`, `structure/`, or `docs-site/`.
 ## User-consent actions
 
 Some actions write to the **user's own accounts and identity** rather than to
-this repository, and an agent must never perform or auto-answer them. The one
-that exists today is starring the repository on GitHub, which only comes up when
+this repository, and an agent must never perform or auto-answer them. One example
+is starring the repository on GitHub, which only comes up when
 an agent is *running* opencodex — not when it is working on this codebase.
 
 The rule lives in [`AGENTS_INSTALL.md`](./AGENTS_INSTALL.md), which is the file

AGENTS_INSTALL.md

@@ -22,7 +22,7 @@ install or operations task authorizes, and an agent must never perform or
 auto-answer them — even when the surrounding task is approved, even when the
 credential is sitting right there.
 
-The current one is **starring the repository on GitHub**.
+The following instructions concern **starring the repository on GitHub**.
 
 ### Do not
 
@@ -72,6 +72,14 @@ agent-driven callers regardless:
 Regression coverage: `tests/server/startup-prompt.test.ts`,
 `tests/cli/agent-driven.test.ts`, `tests/server/sidebar-routes.test.ts`.
 
+### Pending Codex account validation
+
+Completing deferred account validation spends model quota. Only a human's
+dashboard **Refresh quotas** action authorizes it. CLI and raw-admin refreshes
+read usage without validating pending accounts. Relay the dashboard recovery
+instruction to the user; do not mint a GUI session or call the provider directly
+to work around this boundary. This also applies when operating a headless host.
+
 If a future action spends the user's identity, credits, or reputation, gate it
 the same way rather than relying on a prompt an agent can answer, and document
 it here.

README.md

@@ -368,6 +368,9 @@ Maintainer source-of-truth notes live under [`structure/`](./structure), contrib
 Report undisclosed vulnerabilities privately through
 [GitHub private vulnerability reporting](https://github.com/lidge-jun/opencodex/security/advisories/new),
 not a public issue.
+That form is the only technical channel — there is no security email. Follow-ups stay in the
+private report itself; a public issue may carry coordination only, never vulnerability details.
+Acknowledging a report is not the same as triaging it, and no first-response target is promised.
 
 ## Development
 

SECURITY.md

@@ -31,6 +31,38 @@ Include affected versions, reproduction steps, impact, and any required configur
 If the form is ever unreachable for you, open a minimal public issue that asks maintainers for a
 safe coordination path. Do not include exploit details, secrets, or live targets in that issue.
 
+### Public or private
+
+Being findable in the source is not disclosure. opencodex is source-available, so nearly every
+defect here is in principle "visible in the code" — that is not the test, and it is not a reason
+to open a public issue.
+
+The test is whether the weakness is already public: the fix has shipped, or the defect is
+already described in a published advisory, issue, or pull request. When that is true, ordinary
+public review applies and a normal issue or pull request is the right route. When it is not, the
+report is pre-disclosure material and belongs in the private advisory form, whatever its
+severity looks like to you.
+
+If you are unsure, file privately. Maintainers can move a report to public review once it is
+safe to do so; the reverse is not possible.
+
+## Following Up on a Report You Already Filed
+
+Keep follow-up inside the private report. The advisory thread you opened stays open for
+comments, and that is where new evidence, corrected impact, and questions about status belong.
+There is no second private route: GitHub private vulnerability reporting is the only technical
+channel this project offers, and there is no security email to escalate to.
+
+If the private thread itself is stalled or unreachable, a public issue may carry **coordination
+only** — a request for a safe follow-up path, or a note that a filed report is still awaiting a
+response. Keep it free of the vulnerability: no reproduction steps, no exploit reasoning, no
+logs or attachments, no narrowing of affected versions, and no advisory identifiers or links.
+You do not need to say which report you mean; maintainers can match it privately, and naming it
+in public is itself a signal.
+
+A maintainer may answer such an issue in public. Read that answer narrowly — it confirms the
+route, not the content of anything you reported.
+
 ## Response Expectations
 
 Maintainers will review reports on a best-effort basis. Triage usually starts with:
@@ -40,6 +72,19 @@ Maintainers will review reports on a best-effort basis. Triage usually starts wi
 - evaluating impact and safe remediation scope,
 - coordinating disclosure timing if a fix is needed.
 
+Receipt is not triage. An acknowledgment — including a maintainer confirming they can reach the
+private reporting queue — means the message arrived. It does not mean the report has been
+reproduced, assessed for impact, assigned an owner, or accepted. The private thread is the only
+place the technical outcome is recorded.
+
+Public review of a published patch does not close the corresponding private report, and it does
+not settle disclosure for anything else you filed. Landing a fix resolves the handling route for
+that fix; the private report closes when maintainers close it.
+
+There is no response deadline. Review is best-effort, as stated above, and this project does not
+publish a first-response target — please do not read one into an acknowledgment or into the
+triage steps listed here.
+
 ## Operational Notes
 
 - Remove secrets, tokens, cookies, and personal data from screenshots and logs before sharing them.