feat: integrate non-GUI enhancement batch 10B

docs-site/astro.config.mjs

@@ -111,6 +111,7 @@ export default defineConfig({
             { label: "Integrations", translations: { fr: "Intégrations", ko: "연동", "zh-CN": "集成", "zh-TW": "整合", ru: "Интеграции", ja: "連携", tr: "Entegrasyonlar" }, slug: "guides/integrations" },
             { label: "MiniMax clients", translations: { fr: "Clients MiniMax", ko: "MiniMax 클라이언트", "zh-CN": "MiniMax 客户端", "zh-TW": "MiniMax 客戶端", ru: "Клиенты MiniMax", ja: "MiniMax クライアント", tr: "MiniMax İstemcileri" }, slug: "guides/minimax" },
             { label: "Sidecars: Web Search & Vision", translations: { fr: "Services auxiliaires : recherche web et vision", ko: "사이드카: 웹 검색 & 비전", "zh-CN": "边车：网络搜索与视觉", "zh-TW": "邊車：網路搜尋與視覺", ru: "Сайдкары: веб-поиск и зрение", ja: "サイドカー: ウェブ検索 & ビジョン", tr: "Sidecar'lar: Web Arama ve Görme" }, slug: "guides/sidecars" },
+            { label: "Local Plugins", translations: { fr: "Plugins locaux", ko: "로컬 플러그인", "zh-CN": "本地插件", "zh-TW": "本機外掛", ru: "Локальные плагины", ja: "ローカルプラグイン", tr: "Yerel Eklentiler" }, slug: "guides/local-plugins" },
             { label: "Image Bridge", translations: { fr: "Pont d’images", ko: "이미지 브릿지", "zh-CN": "图像桥接", "zh-TW": "圖像橋接", ru: "Image Bridge", ja: "画像ブリッジ", tr: "Image Bridge" }, slug: "guides/image-bridge" },
             { label: "Video Bridge", translations: { fr: "Pont vidéo", ko: "비디오 브릿지", "zh-CN": "视频桥接", "zh-TW": "影片橋接", ru: "Video Bridge", ja: "動画ブリッジ", tr: "Video Bridge" }, slug: "guides/video-bridge" },
             { label: "Web Dashboard", translations: { fr: "Tableau de bord web", ko: "웹 대시보드", "zh-CN": "网页控制台", "zh-TW": "網頁儀表板", ru: "Веб-дашборд", ja: "ウェブダッシュボード", tr: "Web Kontrol Paneli" }, slug: "guides/web-dashboard" },

docs-site/src/content/docs/fr/reference/configuration/providers.md

@@ -86,7 +86,7 @@ sauvegarde dont le contenu diffère, puis réécrit en identifiants sans préfix
 | --- | --- | --- |
 | `adapter` | `string` | L'un des `openai-chat`, `openai-responses`, `anthropic`, `google`, `kiro`, `cursor`, `ollama-native`, `azure-openai` (ou alias `azure`). |
 | `baseUrl` | `string` | URL de base de l'API en amont. La plupart des points de terminaison fixes intégrés ignorent une valeur incompatible ; les préréglages de clés protégés contre les collisions préservent une ancienne destination personnalisée portant le même nom. |
-| `requestPacing?` | `{ enabled, requestsPerMinute?, minIntervalMs?, models? }` | Cadencement facultatif du démarrage des requêtes sortantes côté client, distinct de l’utilisation, de la facturation et des indicateurs de limitation en amont. Le nombre de requêtes par minute est converti en intervalle régulier ; `minIntervalMs` peut imposer un intervalle plus long. Les limites du fournisseur s’appliquent à tous ses modèles, tandis que les entrées `models` ciblent les identifiants exacts des modèles en amont, par exemple `nvidia/llama-3.1-nemotron-ultra-253b-v1`, et ne peuvent qu’ajouter du délai. L’attente dans la file ne consomme pas le délai d’expiration des en-têtes de réponse en amont. Les requêtes HTTP, Responses WebSocket et les distributions explicites `fetchResponse`/`runTurn` des adaptateurs sont couvertes. |
+| `requestPacing?` | `{ enabled, requestsPerMinute?, minIntervalMs?, maxConcurrentRequests?, models? }` | Cadencement facultatif du démarrage des requêtes sortantes côté client, distinct de l’utilisation, de la facturation et des indicateurs de limitation en amont. `maxConcurrentRequests` est une limite entière positive des requêtes en cours ; une règle fournisseur ou modèle peut utiliser uniquement cette limite. Les limites du fournisseur s’appliquent à tous ses modèles, tandis que les entrées `models` ciblent les identifiants exacts des modèles en amont et peuvent ajouter du délai ou réduire la concurrence. L’attente dans la file ne consomme pas le délai d’expiration des en-têtes de réponse en amont. Les requêtes HTTP et les distributions explicites `fetchResponse`/`runTurn` des adaptateurs sont couvertes. Avec une limite de concurrence, un tour Responses WebSocket canonique utilise HTTP/SSE afin de libérer la capacité à la fin, en cas d’erreur ou d’annulation du corps de réponse. Pour les adaptateurs `runTurn`, dont Cursor, la limite compte les tours actifs plutôt que les envois physiques : RunSSE et BidiAppend peuvent se chevaucher dans un même tour, tandis qu’un autre tour attend. Les envois suivants respectent toujours les intervalles de démarrage. |
 | `responsesPath?` | `string` | Chemin de ressource relatif pour les requêtes d'authentification par clé `openai-responses`. Il doit commencer par `/` et ne contenir aucun schéma, requête ou fragment. |
 | `chatCompletionsPath?` | `string` | Chemin de ressource relatif pour les requêtes `openai-chat`, miroir de `responsesPath` et soumis aux mêmes règles de forme. Nécessaire lorsqu'un même service en amont sert Chat Completions et Responses sous des préfixes différents : un override wire par modèle change l'adaptateur sans toucher `baseUrl`, donc sans ce réglage une requête Chat activée serait envoyée vers la base Responses. L'exemple fourni est Z.AI. |
 | `upstreamWebsocket?` | `boolean` | Active le transport Responses WebSocket en amont pour les requêtes `openai-responses` (désactivé par défaut). N'est honoré que pour l'amont first-party `https://api.openai.com/v1` ; les points de terminaison des fournisseurs personnalisés utilisent toujours HTTP/SSE borné, car Bun ne peut pas appliquer de limite de taille aux messages WebSocket entrants avant d'avoir alloué le message complet. Pour le fournisseur canonique ChatGPT `openai`, l'omettre conserve le WebSocket en amont sur les tours éligibles, `false` envoie les tours en streaming via HTTP/SSE, et `true` est refusé ; avec `false`, le pilotage et l'injection natifs en cours de tour sont indisponibles. Ce champ est indépendant du réglage `websockets` côté client et ne change ni le point de terminaison ni les identifiants. Une base HTTP reste en SSE ; les chemins qui ne sont pas Responses et les requêtes `openai-chat` restent en HTTP. |

docs-site/src/content/docs/guides/codex-integration.md

@@ -477,6 +477,42 @@ While the mode is active, the realtime voice sideband override
 (`experimental_realtime_ws_base_url`) is not injected — the dedicated provider-table form cannot
 carry it — so Codex Desktop voice uses its native endpoint rather than the proxy.
 
+### Emergency compaction model (opt-in)
+
+`compactionRecovery` leaves the initial compaction on the conversation's selected route. It
+permits one emergency attempt only after a supported, pre-output compaction failure. It is
+separate from `compactionRouting`, which chooses another model before compaction starts, and
+from `codexClientCompaction`, which changes Codex's provider form.
+
+```json
+{
+  "compactionRecovery": {
+    "enabled": true,
+    "model": "provider/emergency-model",
+    "allowDevinInvalidArgument": false
+  }
+}
+```
+
+Use an independently configured, authorized model with enough context for the failed input.
+Enabling recovery permits that model's provider to receive the compaction history and charge
+for the extra attempt when recovery runs; ordinary successful compactions incur no extra call.
+The option is off when absent or disabled. The existing authenticated management API accepts
+this block through `PUT /api/settings`; send `compactionRecovery: null` to remove it. A direct
+file edit should follow the normal stopped-proxy configuration workflow. This setting does not
+change sign-in, the conversation's ordinary model, Codex's provider ID, or the desktop composer.
+
+Recovery does not replay after cancellation, semantic output, tool side effects, an exhausted
+send budget, or an authentication, admission or policy refusal. Generic `400` errors do not
+enable fallback. The separately opted-in Devin `invalid_argument` case applies only to an
+identified compaction failure from that adapter. The emergency attempt shares the original
+request's send budget and never starts a second recovery attempt.
+
+Native encrypted compaction is outside this recovery path: its original error is retained.
+There is no automatic local truncation mode. A response being accepted is not proof that a
+long conversation retained its goals; verify the next turn on the original model before
+treating an emergency summary as a recovered task.
+
 ### Authless Codex Desktop (opt-in)
 
 In **Dashboard → Overview**, **Open Codex without signing in** controls this existing

docs-site/src/content/docs/guides/local-plugins.md

@@ -0,0 +1,105 @@
+---
+title: Local Plugins
+description: Load your own code into the proxy at startup to rewrite provider sends, for example to put a local compression proxy in front of providers.
+---
+
+A local plugin is a TypeScript or JavaScript file that `ocx start` loads before the proxy begins
+serving. It can see every provider send just before it leaves the process and redirect it or add
+headers — enough to place a local sidecar (a compression proxy, a recorder) in front of providers
+without changing opencodex itself.
+
+Plugins are local to one install. opencodex does not download, update or sign them.
+
+## Where plugins live
+
+Put plugin files in `plugins/` inside the opencodex home (`~/.opencodex/plugins/`, or
+`$OPENCODEX_HOME/plugins/` when that variable is set):
+
+```text
+~/.opencodex/plugins/
+  my-sidecar.ts
+```
+
+- Files ending in `.ts`, `.js` or `.mjs` are loaded in name order.
+- Names starting with `.` or `_`, and `*.d.ts`, are ignored — rename a plugin to `_my-sidecar.ts`
+  to switch it off.
+- The directory is optional. Without it nothing is loaded.
+- A plugin runs inside the proxy with your credentials, so opencodex refuses a plugin file or a
+  `plugins/` directory that is owned by another user or writable by group or others, and refuses
+  symbolic links. Every directory above `plugins/`, up to `/`, must also be owned by you or root and
+  not writable by group or others, unless it is sticky like `/tmp`. Fix permissions with
+  `chmod go-w ~/.opencodex/plugins ~/.opencodex/plugins/*`; on systems whose default umask is
+  `002`, check the parent directories too. On macOS, any ACL on the file or a path directory also
+  blocks loading, even if its mode is `0600`; inspect with `ls -le`. On Linux, extended ACLs are
+  checked when `getfacl` is installed. Without it, only owner and mode bits are verified.
+- On Windows automatic plugin loading is disabled until an ACL trust check is available.
+
+Restart the proxy after adding, changing or removing a plugin (`ocx service restart`, or stop and
+start `ocx start`). Each loaded plugin prints a `Plugin loaded: <name>` line at startup; a skipped
+plugin prints a bounded reason category. Raw plugin exception text is never printed automatically.
+
+To start once without plugins, set `OCX_PLUGINS=0`.
+
+## Writing a plugin
+
+A plugin default-exports an object with an optional `name` and a `setup` function. `setup` receives a
+context. An asynchronous `setup` has five seconds to finish; plugins run in the proxy's own thread, so
+a `setup` that blocks synchronously cannot be interrupted and delays startup until it returns. A
+`setup` that times out is not stopped either: servers or timers it already started keep running, so
+start long-lived resources only after the work that can fail.
+
+```ts
+interface UpstreamTarget {
+  url: string;            // absolute upstream URL; assign a new one to redirect
+  headers: Headers;       // outbound headers, including credentials — never log them
+  readonly transport: "http" | "websocket";
+}
+
+export default {
+  name: "my-sidecar",
+  setup(ctx: {
+    log(message: string): void;
+    registerUpstreamRewriter(rewrite: (target: UpstreamTarget) => void): void;
+    onShutdown(teardown: () => void): void;
+  }) {
+    ctx.registerUpstreamRewriter(target => {
+      const upstream = new URL(target.url);
+      if (!upstream.pathname.endsWith("/chat/completions")) return;
+      target.url = `http://127.0.0.1:9000${upstream.pathname}${upstream.search}`;
+      target.headers.set("x-original-origin", upstream.origin);
+    });
+  },
+};
+```
+
+The context also carries `name`, `configDir` (the opencodex home) and `pluginDir`.
+
+Plugins cannot import opencodex modules — in the packaged binary they are not on disk. Declare the
+small interfaces you need locally, as above.
+
+## How rewrites behave
+
+- The rewriter runs synchronously on every provider send over HTTP and on the Codex WebSocket
+  connection, after opencodex has picked the transport. Keep it fast; do network checks (health
+  probes) in the background and read a cached result in the rewriter.
+- A send redirected to a loopback address (`127.0.0.1`, `::1`, `localhost`) connects directly, over
+  HTTP and over the Codex WebSocket, ignoring provider proxies and `HTTP_PROXY`: a proxy elsewhere
+  cannot reach this machine's loopback. Any other destination follows the normal egress settings
+  (including `NO_PROXY`), evaluated against the rewritten URL, on both transports.
+- The Codex WebSocket rewriter runs for every turn, before an idle pooled socket is reused, and a
+  socket is only reused for the same destination and the same rewritten headers, apart from the two
+  per-turn headers `x-codex-turn-state` and `x-codex-turn-metadata`. Those travel inside each
+  request frame and may differ between exchanges on one socket; changes a rewriter makes to them
+  are discarded. A plugin that starts or stops redirecting takes
+  effect on the next turn.
+- It runs after opencodex has chosen the provider, account and route, so it does not change routing,
+  account selection, retries or request logs.
+- A redirected send goes to the host you chose. That host sees the request exactly as the provider
+  would, credentials included.
+- If a rewriter throws, opencodex undoes that rewriter's edits to the send and disables it for the
+  rest of the process. Edits made by rewriters that ran before it are kept, so the send goes out as
+  those left it (unmodified when it is the only plugin). If `setup` throws or times out, the plugin is skipped,
+  anything it registered is removed, and later registration attempts from it are ignored; other
+  plugins and the proxy start normally.
+- A plugin directory that exists but cannot be read (for example, wrong permissions) is reported at
+  startup rather than treated as empty.

docs-site/src/content/docs/guides/providers.md

@@ -902,10 +902,12 @@ OpenCodex provides official adapter support for Tencent Cloud's CodeBuddy Code C
   - Global: [CodeBuddy Global API Keys](https://www.codebuddy.ai/profile/keys)
   - CN: [CodeBuddy CN API Keys](https://copilot.tencent.com/profile/keys)
 - **Region Isolation:** `codebuddy` and `codebuddy-cn` use separate canonical endpoints (`https://www.codebuddy.ai` and `https://www.codebuddy.cn`) and isolated child environments (`CODEBUDDY_INTERNET_ENVIRONMENT=public` vs `internal`). Credentials are strictly region-scoped and never exchanged across environments. Overriding the canonical base URL fails closed.
+- **Model Discovery:** the proxy requests the CodeBuddy product configuration (`GET {baseUrl}/v3/config`) with the configured key as the `X-API-Key` header, and the roster in that answer is the authoritative roster of discovered models: it is the key's own account configuration, so it is proven to belong to the key — a different or wrong key answers the anonymous envelope with no roster instead of another account's models. The authenticated roster is the same list the CLI prints for `--model` (the "Currently supported" line of a signed-in CLI), can differ from the static manifest bundled with the CLI, and the vendor default selectors (`default` for CN, `default-model` for Global) never appear in it but remain callable: the catalog retains them during live discovery and on every fallback path. On start/sync the proxy binds the cached roster to an irreversible fingerprint of the configured key, so a key switch never observes a roster cached for the previous key, and degrades to the stale provider/key-fingerprint-scoped cache, then to the static seed in `src/providers/codebuddy-models.ts`, when the key does not authenticate or the request fails. Discovery failure logs contain only a category and HTTP status, without the gateway's message or a raw transport exception.
+  The credentialed discovery request does not follow redirects; a 3xx response degrades the roster without forwarding the key to another origin.
 - **Tool Ownership and the Tool Bridge:** The CLI is always spawned with `--tools ""` and `--strict-mcp-config`, so it has no built-in or user-configured tools of its own. When a request carries a Codex tool catalog, the provider arms a capture-only MCP bridge: the validated catalog and MCP config are written to a private temp dir, the CLI is launched with `--mcp-config` and an exact `--allowedTools` list, and the `system/init` frame must report exactly that bridge server as connected or the turn fails closed. The bridge advertises the Codex tools and captures proposed calls but never executes anything: a completed tool-call batch is returned as `function_call` items (names mapped back to the request's wire names, at most 16 calls per assistant message), the process tree is terminated at `message_stop`, and the external Codex client alone performs approval, sandboxing, and execution. Tool results come back as the next request's input, and the conversation continues. Requests without tools keep the plain text-and-reasoning shape. If the CLI writes an unquoted DSML `calls` control line followed by a `functions.*` invoke control line into text or reasoning, OpenCodex refuses the turn instead of forwarding the scaffold or interpreting it as an executable call. DSML discussed or quoted in prose, inline code, fenced code, or source examples remains ordinary answer text.
-- **Entitlements and Billing:** The provider uses the same vendor-documented CodeBuddy account/CLI authentication surface. Availability and billing of free, promotional, trial, or subscription credits remain determined by the user's CodeBuddy account entitlement.
 - **Tool Choice Enforcement:** When a request specifies `tool_choice: "required"` or selects a specific named tool, the bridge expects a tool call from the model. If the CLI completes the turn with plain text instead of capturing a tool call, OpenCodex fails closed with a 502 `tool_call_required` error rather than returning an invalid text completion.
 - **Governance Status:** Whether routing this vendor automation surface behind a proxy for a third-party agent satisfies CodeBuddy's acceptable-use terms is an open question flagged for maintainer security review (see the governance note in the provider registry entry). Treat this provider as pending that review, and keep the tool bridge's ownership boundary in mind: the nested CLI advertises tools but never executes them, and approval, sandboxing, and execution remain with the external Codex client.
+- **Entitlements and Billing:** The provider uses the same vendor-documented CodeBuddy account/CLI authentication surface. Availability and billing of free, promotional, trial, or subscription credits remain determined by the user's CodeBuddy account entitlement.
 
 ### Official Qoder CLI (Global & CN)