feat(gateway): opt-in stripping of Codex connector/app tools for shared OAuth accounts

[kangjwme]

Background

sub2api shares one upstream ChatGPT/Codex OAuth account across many downstream API keys. On the Codex OAuth forward path the request tools array is forwarded verbatim (only structurally normalized in normalizeCodexTools).

ChatGPT connector/app tools (the codex_apps.* namespace — GitHub, Google Drive, Gmail, …) are executed server-side by OpenAI under the account owner's identity. Concretely, the GitHub connector performs actions as the account owner's linked GitHub identity (see openai/codex#24735), and the connector tools are surfaced under the codex_apps MCP namespace (openai/codex#10750).

Consequence: when an OAuth account that has connectors enabled is shared, a downstream caller can include codex_apps.* tools in their request and have them run with the account owner's connector credentials (e.g. read the owner's private repos). The proxy currently applies no per-key tool authorization.

Change

Add an opt-in flag gateway.codex_block_connector_tools (default false, no behavior change). When enabled, before forwarding a Codex OAuth request the gateway:

• drops tools in the codex_apps.* namespace and connector-enumeration tools (app/list, apps/list, mcpServerStatus/list, list_connectors, connectors/list);
• resets a tool_choice that pinned a removed tool back to "auto" (avoids an upstream "unknown tool" error);
• logs a WARN with the stripped tool names.

Name matching normalizes ., -, / to _, so codex_apps.github.get_repo, codex_apps__github__get_repo and codex_apps-github-get_repo all match, while suffix-only names like my_codex_apps and separator-less codexapps are left untouched.

Wired into all three Codex OAuth forward paths: ForwardAsAnthropic (messages), ForwardAsChatCompletions, and the /v1/responses Forward. The existing applyCodexOAuthTransform wrapper is preserved; only the two production call sites were switched to ...WithOptions to thread the flag.

Default / compatibility

Default is false to match the project's existing Codex flag convention (force_codex_cli, codex_image_generation_bridge_enabled, …) and to avoid changing behavior for existing deployments. Shared-account / multi-tenant operators are advised to enable it. Happy to flip the default to secure-by-default if preferred.

Tests

• New unit tests: name matching (incl. false-positive guards), stripping behavior, tool_choice reset, and that the default (flag off) leaves the connector tool in place.
• Full module test suite green (go test ./...), incl. internal/service, internal/handler, apicompat, openai_ws_v2.
• gofmt clean; changed code passes golangci-lint.

Notes / follow-ups (not in this PR)

The strongest mitigation remains operational: don't enable connectors on accounts shared into the proxy. Possible follow-ups: per-API-key/group tool allow/block lists, and namespacing previous_response_id on the WS v2 path.