sync: upstream v2.50.0 (2d4d7a223) into dev

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

.github/workflows/cleanup-orphaned-workflows.yml

@@ -37,7 +37,7 @@ jobs:
       - name: Setup Bun
         uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2
         with:
-          bun-version: 1.3.14
+          bun-version: 1.4.2
 
       - name: Remove stale workflow histories
         env:

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.

Dockerfile

@@ -1,7 +1,7 @@
 # syntax=docker/dockerfile:1
 
 # Keep the runtime aligned with package.json and pin the multi-platform image index.
-ARG BUN_IMAGE=oven/bun:1.4.0@sha256:5ff609364c049b54eb0ff560ec96319729a972078ef2c755d758f0c6ef89c2d6
+ARG BUN_IMAGE=oven/bun:1.4.2@sha256:9114c058aeae42162ee16dd5084b95fe9473970bb6bcb5b232ab1630f0546895
 
 FROM ${BUN_IMAGE} AS build
 WORKDIR /home/bun/app

README.md

@@ -106,16 +106,19 @@ See [SPONSORS.md](./SPONSORS.md).
 
 <!-- sponsors:main — one banner, model developers only; empty until a Main sponsor signs -->
 
-<!-- sponsors:standard — one row per sponsor, in order of signing. Uncomment the table with the first row:
+<!-- sponsors:standard — one row per sponsor, in order of signing -->
 <table>
 <tbody>
 <tr>
-<td width="180"><a href="SPONSOR_URL"><img src="https://raw.githubusercontent.com/lidge-jun/opencodex/main/assets/sponsors/SPONSOR.png" alt="SPONSOR" width="150"></a></td>
-<td>Thanks to SPONSOR for sponsoring this project! BLURB</td>
+<td width="180"><a href="https://www.orcarouter.ai/?utm_source=opencodex&utm_medium=readme"><img src="assets/sponsors/orcarouter.png" alt="OrcaRouter" width="150"></a></td>
+<td>Thanks to <a href="https://www.orcarouter.ai/?utm_source=opencodex&utm_medium=readme">OrcaRouter</a> for sponsoring this project! OrcaRouter is one OpenAI-compatible AI gateway for production AI: adaptive routing that grades every prompt and sends it to the model that clears your bar, automatic failover, routing rules as code, zero-markup provider pricing with prompt caching, and guardrails, an agent firewall, and request logs on every call across 200+ models. Pick <code>OrcaRouter</code> in the Add provider picker or run <code>ocx provider add orcarouter</code>; <code>orcarouter/auto</code> is the adaptive router.</td>
+</tr>
+<tr>
+<td width="180"><a href="https://www.packyapi.com/register?aff=k5KT"><img src="assets/sponsors/packycode.png" alt="PackyCode" width="150"></a></td>
+<td>Thanks to <a href="https://www.packyapi.com/register?aff=k5KT">PackyCode</a> for sponsoring this project! PackyCode is a stable, high-performance API relay provider, offering relay services for Claude Code, Codex, Gemini, and more. With automatic failover, smart routing, and unlimited concurrency, it turns AI into a real productivity tool. <a href="https://www.packyapi.com/register?aff=k5KT">Register via this link</a> and get started! Pick <code>PackyCode</code> in the Add provider picker or run <code>ocx provider add packycode</code>.<br><sub>PackyCode 是一家稳定、高效的 API 中转服务商，提供 Claude Code、Codex、Gemini 等多种中转服务。具备自动故障转移、智能路由和无限并发等多种功能，让 AI 编程成为真正的生产力工具。<a href="https://www.packyapi.com/register?aff=k5KT">点此链接注册</a>，立即开始使用！</sub></td>
 </tr>
 </tbody>
 </table>
--->
 
 ---
 
@@ -303,7 +306,7 @@ full-slash form keeps working too. Details: [model routing docs](https://opencod
 OpenAI (ChatGPT login or API key), Anthropic, Google Gemini, xAI, Kimi, Azure OpenAI, Ollama
 (local + Cloud), Cursor (experimental), and every OpenAI-compatible endpoint — plus DeepSeek,
 Groq, OpenRouter, Together, Fireworks, Cerebras, Mistral, Hugging Face, NVIDIA NIM, MiniMax,
-Qwen Cloud, SiliconFlow, and more. Full list: `ocx init` or the
+Qwen Cloud, Qoder Global and CN (official PAT + CLI), SiliconFlow, and more. Full list: `ocx init` or the
 [provider docs](https://opencodex.me/guides/providers/).
 
 ## CLI
@@ -384,6 +387,9 @@ Maintainer source-of-truth notes live under [`structure/`](./structure), contrib
 Report undisclosed vulnerabilities privately through
 [GitHub private vulnerability reporting](https://github.com/yansigit/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.

SPONSORS.md

@@ -45,7 +45,7 @@ sponsor receives:
   supplied by the sponsor and published verbatim. The maintainer may decline or require edits to
   text that is false, misleading, disparages third parties, or breaches applicable law or GitHub
   policy. A second-language blurb (for example Chinese) may run alongside the English one.
-- A built-in provider preset (`ocx provider select <id>`) shipped in a public npm release,
+- A built-in provider preset (`ocx provider add <id>`) shipped in a public npm release,
   listed near the top of the provider picker in the dashboard and CLI and marked as a sponsor
   there. (The registry field and picker ordering that back this land with the first sponsor
   preset; today the picker follows registry order.)