Skip to content

feat: add OrcaRouter as a named inference provider - #736

Open
martinzudergaming-a11y wants to merge 1 commit into
openai:mainfrom
martinzudergaming-a11y:feat/add-orcarouter-provider
Open

feat: add OrcaRouter as a named inference provider#736
martinzudergaming-a11y wants to merge 1 commit into
openai:mainfrom
martinzudergaming-a11y:feat/add-orcarouter-provider

Conversation

@martinzudergaming-a11y

Copy link
Copy Markdown

Summary

Codex Security is a CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities in your code. When users want to scan through an inference provider other than OpenAI's first-party endpoint, they already reach for the "Other providers" section of the README and pass --provider openrouter or --provider fireworks with that provider's API key.

This PR adds OrcaRouter as a first-class provider in that same registry, so users can run:

export ORCAROUTER_API_KEY="<your-orcarouter-api-key>"
codex-security scan . --provider orcarouter --model orcarouter/fusion

instead of treating OrcaRouter as an anonymous custom base URL.

Changes

  • Register ORCAROUTER_CODEX_PROVIDER in EXTERNAL_CODEX_PROVIDERS (sdk/typescript/src/config.ts), mirroring OPENROUTER_CODEX_PROVIDER: base_url https://api.orcarouter.ai/v1, env_key ORCAROUTER_API_KEY, wire_api responses.
  • Accept orcarouter in the CLI --provider enum and the generated help text (sdk/typescript/src/cli.ts).
  • Add ORCAROUTER_API_KEY to the ScanAuthentication source unions and the selected-scan-environment filter in sdk/typescript/src/api.ts, so the key is forwarded to the Codex runtime exactly like the other external provider keys.
  • Add ORCAROUTER_API_KEY to the plugin helper secret environment variables (sdk/typescript/src/runtime.ts) and to the MCP server's allowed env_vars (plugins/codex-security/.mcp.json and its smoke test), so the key never leaks into helper subprocesses.
  • Extend the existing provider test cases (API, CLI, preflight config, runtime, events) and both README quick-start examples with the OrcaRouter provider.

Because the provider registry is data-driven, the existing isExternalModelProvider / EXTERNAL_CODEX_PROVIDERS[provider] paths pick up the new entry without any provider-specific branching.

Testing

  • pnpm run lint (tsc --noEmit) passes.
  • pnpm run types (generated models check, MCP typecheck, tsc) passes.
  • pnpm run format (Prettier) passes.
  • Provider test suites pass: api.test.ts 141 pass / 0 fail, cli.test.ts 147 pass / 0 fail, runtime.test.ts 132 pass / 0 fail, api-preflight-config.test.ts 17 pass / 0 fail, api-events.test.ts 36 pass / 0 fail.
  • Live check against OrcaRouter's Responses API returned HTTP 200 using the registered base_url and ORCAROUTER_API_KEY, and the generated Codex config emits model_provider: orcarouter with the expected model_providers.orcarouter block.

Note: the full local suite has pre-existing failures in git-blob-bound tests (compact-diff-scan, diff-rank-input) and an MCP smoke test that require ripgrep; these fail identically on the pristine checkout in this container and are unrelated to this change.

Risk and rollout

No behavioral change for existing providers; orcarouter is an additive enum value. The new provider requires users to supply their own ORCAROUTER_API_KEY, matching the existing OpenRouter/Fireworks flow. No credentials, findings, or private links are included.

Public disclosure review

  • No customer, partner, prospect, or user identities, data, or identifying details are included.
  • No credentials, personal data, private source, scan findings, or nonpublic links or tickets are included.
  • I reviewed the branch name, title, description, commits, changes, comments, logs, screenshots, attachments, and links for public disclosure.

OrcaRouter is an OpenAI-compatible AI gateway built for both models and agents. Like OpenRouter, it exposes a provider/model namespace across many models — but it also combines adaptive routing, automatic failover, zero-markup inference, observability, guardrails, and agent-tool governance behind the same endpoint. Adding orcarouter as a first-class provider means Codex Security users can use that stack directly, without treating OrcaRouter as an anonymous custom base URL.

It also runs gateway-level, zero-trust security for AI agents on the same endpoint — screening every prompt/response and governing every tool call on a default-deny basis, with no application code changes.

Discord: discord.gg/YEubt8enRA · X: https://x.com/OrcaRouter

I'm an engineer on the OrcaRouter team.

Add orcarouter to the external Codex providers so users can run scans
through OrcaRouter with `--provider orcarouter`, mirroring the existing
OpenRouter and Fireworks integrations.

- Register ORCAROUTER_CODEX_PROVIDER (base_url, env_key, wire_api)
- Accept orcarouter in the CLI --provider enum and help text
- Forward ORCAROUTER_API_KEY through the MCP worker and plugin environment
- Cover the new provider in API, CLI, runtime, and preflight tests
- Document the orcarouter quick-start example in both READMEs
@github-actions github-actions Bot added the enhancement New feature or request label Aug 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant