@christiandoxa/prodex 0.232.0 → 0.233.0

package/README.md

@@ -94,7 +94,9 @@ curl http://127.0.0.1:4000/v1/responses \
 <details>
 <summary>Gateway capabilities (advanced)</summary>
 
-The gateway serves `/v1/responses`, `/v1/chat/completions`, `/v1/embeddings`, `/v1/images/*`, `/v1/audio/*`, `/v1/batches`, `/v1/rerank`, `/v1/a2a`, `/v1/messages`, and `/v1/models` where the selected upstream supports them. It adds `x-prodex-call-id` to responses, writes local request detail plus `gateway_spend` events for both `request` and `response` phases to runtime logs, can export those events to JSONL or HTTP using generic, OTel, Datadog, or Langfuse-shaped payloads, supports catalog-backed policy routing strategies (`fallback`, `round-robin`, `least-busy`, `lowest-cost`, `lowest-latency`, `rpm`, `tpm`, `first`) for model aliases/fallback chains, can enforce static virtual keys with persisted request/spend usage plus model/budget/RPM/TPM limits, supports file, SQLite, Postgres, or Redis-backed gateway admin/usage/ledger/SCIM state, and can apply keyword/model, local PII redaction, Presidio, and external webhook guardrails before calls and on outputs. Admin-token, trusted-proxy SSO, or OIDC/JWT bearer requests can list usage, create generated-token keys, rotate/disable/update/delete admin-managed keys, provision SSO users through SCIM-compatible `/v1/prodex/gateway/scim/v2/Users`, inspect usage at `/v1/prodex/gateway/keys` and `/v1/prodex/gateway/usage`, read recent billing ledger records with response-status/output-token reconciliation at `/v1/prodex/gateway/ledger`, read aggregated billing totals at `/v1/prodex/gateway/ledger/summary`, export billing CSV from `/v1/prodex/gateway/ledger.csv` and `/v1/prodex/gateway/ledger/summary.csv`, scrape Prometheus text metrics at `/v1/prodex/gateway/metrics`, inspect provider adapter contracts at `/v1/prodex/gateway/providers`, inspect active observability and guardrail configuration at `/v1/prodex/gateway/observability` and `/v1/prodex/gateway/guardrails`, fetch the machine-readable gateway contract at `/v1/prodex/gateway/openapi.json`, and open the built-in gateway admin dashboard at `/v1/prodex/gateway/admin`; policy/env-backed keys remain read-only, SCIM users can carry tenant/team/project/user/budget scopes for SSO/OIDC fallback, admin-managed key and SCIM user mutations are recorded in `prodex audit`, and additional admin-plane tokens can be `admin` or read-only `viewer` with optional virtual-key prefix plus tenant/team/project/user/budget scopes. Configure defaults under `[gateway]` in `policy.toml`; validate provider catalog edits with `npm run catalog:providers`.
+The gateway serves `/v1/responses`, `/v1/chat/completions`, `/v1/embeddings`, `/v1/images/*`, `/v1/audio/*`, `/v1/batches`, `/v1/rerank`, `/v1/a2a`, `/v1/messages`, and `/v1/models` where the selected upstream supports them. It adds `x-prodex-call-id` to responses, writes local request detail plus `gateway_spend` events for both `request` and `response` phases to runtime logs, can export those events to JSONL or HTTP using generic, OTel, Datadog, or Langfuse-shaped payloads, supports catalog-backed policy routing strategies (`fallback`, `round-robin`, `least-busy`, `lowest-cost`, `lowest-latency`, `rpm`, `tpm`, `first`) for model aliases/fallback chains, can enforce static virtual keys with persisted request/spend usage plus model/budget/RPM/TPM limits, supports file, SQLite, Postgres, or Redis-backed gateway admin/usage/ledger/SCIM state, and can apply keyword/model, local PII redaction, Presidio, and external webhook guardrails before calls and on outputs. Admin-token, trusted-proxy SSO, or OIDC/JWT bearer requests can list usage, create generated-token keys, rotate/disable/update/delete admin-managed keys, provision SSO users through SCIM-compatible `/v1/prodex/gateway/scim/v2/Users`, inspect usage at `/v1/prodex/gateway/keys` and `/v1/prodex/gateway/usage`, read recent billing ledger records with response-status/output-token reconciliation at `/v1/prodex/gateway/ledger`, read aggregated billing totals at `/v1/prodex/gateway/ledger/summary`, export billing CSV from `/v1/prodex/gateway/ledger.csv` and `/v1/prodex/gateway/ledger/summary.csv`, scrape Prometheus text metrics at `/v1/prodex/gateway/metrics`, inspect provider adapter contracts at `/v1/prodex/gateway/providers` or offline with `prodex gateway providers --json`, inspect active observability and guardrail configuration at `/v1/prodex/gateway/observability` and `/v1/prodex/gateway/guardrails`, fetch the machine-readable gateway contract at `/v1/prodex/gateway/openapi.json`, and open the built-in gateway admin dashboard at `/v1/prodex/gateway/admin`; policy/env-backed keys remain read-only, SCIM users can carry tenant/team/project/user/budget scopes for SSO/OIDC fallback, admin-managed key and SCIM user mutations are recorded in `prodex audit`, and additional admin-plane tokens can be `admin` or read-only `viewer` with optional virtual-key prefix plus tenant/team/project/user/budget scopes. Configure defaults under `[gateway]` in `policy.toml`; validate provider catalog edits with `npm run catalog:providers`. The generated provider matrix lives in [docs/provider-capabilities.md](./docs/provider-capabilities.md).
+
+`[gateway.adaptive_routing]` is a shadow-mode foundation for owner-attributed quality feedback and route recommendations. Live gateway routing remains deterministic unless a future explicit adaptive policy is enabled, and continuation affinity still wins over any recommendation.
 
 JavaScript clients can use `@christiandoxa/prodex-gateway-sdk` for `/v1/responses` plus gateway key, usage, billing ledger, metrics, and OpenAPI admin calls.
 
@@ -972,6 +974,10 @@ prodex run --respect-system-proxy
 
 Codex `multiAgentMode` is an app-server/thread setting, not a normal TUI `config.toml` launch override. Prodex therefore does not invent a competing CLI config flag. Launch `prodex app-server` or `prodex run app-server` and pass upstream `multiAgentMode` values (`none`, `explicitRequestOnly`, or `proactive`) through the Codex app-server API.
 
+`prodex mcp-server`, `prodex app-server`, and `prodex exec-server` are direct Codex command-server passthroughs by default. Prodex selects the profile `CODEX_HOME` and preserves upstream protocol arguments, but it does not wrap stdio, inject the runtime proxy, rotate accounts inside the protocol, or apply gateway guardrails to those command-server streams. A future broker mode may add JSON-RPC-aware routing behind explicit opt-in; default passthrough remains the compatibility path.
+
+`prodex app-server-broker --json` exposes the current broker-ready contract skeleton. It recognizes JSON-RPC lifecycle methods such as `initialize`, `thread/start`, `thread/resume`, `thread/fork`, `turn/start`, and `turn/cancel`, but stdio brokering is still disabled; `--experimental-stdio` fails loudly instead of corrupting protocol traffic.
+
 Codex plugin catalog commands are managed passthrough by default:
 
 ```bash
@@ -1327,6 +1333,10 @@ In practice, profile `history.jsonl`, `sessions`, `archived_sessions`, `config.t
 
 Codex 0.140.0 defaults CLI auth credentials to the file store, so managed Prodex profiles continue to keep `auth.json` isolated per profile, including OpenAI, API-key, and Bedrock API-key auth JSON. MCP OAuth defaults to Codex `auto`; when it falls back to the file store, `.credentials.json` is shared with direct Codex. OS keyring-backed MCP OAuth credentials remain Codex/OS-owned and are not part of Prodex profile export bundles.
 
+Prodex's own `prodex-secret-store` keyring backend is currently unavailable. If `PRODEX_SECRET_BACKEND=keyring` or `[secrets].backend = "keyring"` is selected, `prodex doctor` and `prodex info` report an invalid backend instead of silently pretending that OS keyring storage is active. Use `backend = "file"` until a real OS keyring implementation is enabled.
+
+Prodex strips dynamic-loader injection variables such as `LD_PRELOAD`, `LD_AUDIT`, `LD_LIBRARY_PATH`, and `DYLD_*` from Codex child processes by default. Set `PRODEX_ALLOW_UNSAFE_CHILD_ENV=1` only when intentionally debugging a custom local runtime environment.
+
 Codex cloud-managed config bundle caches are identity/account scoped and remain profile-local. System-level Codex requirements and managed config files remain owned by upstream Codex and the operating system.
 
 Prodex does not synthesize legacy Codex `[profiles.*]` behavior. File-based Codex profile config selected by `--profile` stays in shared Codex state, while Prodex-owned account selection remains in Prodex profile metadata.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@christiandoxa/prodex",
-  "version": "0.232.0",
+  "version": "0.233.0",
   "description": "Multi-provider Codex wrapper with OpenAI quota-aware routing and Claude Code support",
   "license": "Apache-2.0",
   "bin": {
@@ -16,12 +16,12 @@
     "@openai/codex": "latest"
   },
   "optionalDependencies": {
-    "@christiandoxa/prodex-linux-x64": "0.232.0",
-    "@christiandoxa/prodex-linux-arm64": "0.232.0",
-    "@christiandoxa/prodex-darwin-x64": "0.232.0",
-    "@christiandoxa/prodex-darwin-arm64": "0.232.0",
-    "@christiandoxa/prodex-win32-x64": "0.232.0",
-    "@christiandoxa/prodex-win32-arm64": "0.232.0",
+    "@christiandoxa/prodex-linux-x64": "0.233.0",
+    "@christiandoxa/prodex-linux-arm64": "0.233.0",
+    "@christiandoxa/prodex-darwin-x64": "0.233.0",
+    "@christiandoxa/prodex-darwin-arm64": "0.233.0",
+    "@christiandoxa/prodex-win32-x64": "0.233.0",
+    "@christiandoxa/prodex-win32-arm64": "0.233.0",
     "@openai/codex-linux-x64": "npm:@openai/codex@linux-x64",
     "@openai/codex-linux-arm64": "npm:@openai/codex@linux-arm64",
     "@openai/codex-darwin-x64": "npm:@openai/codex@darwin-x64",