Client or integration
Claude Code, launched through ocx claude -p against a local OpenCodex proxy.
Area
Authentication and account pool
Summary
With the Anthropic OAuth account pool enabled and Account A displayed as Active, a successful ocx claude -p request for a genuine Claude model used the Claude Code login belonging to Account B. OpenCodex recorded the request as anthropic-native.
I understand that native passthrough intentionally preserves the caller's subscription credentials. The problem is the interaction with an explicitly enabled account pool: the dashboard's Active account and quota strategy do not govern these requests, without making that exception apparent in the pool controls. Users cannot rely on the pool settings to control which account their OCX-launched Claude work consumes.
The account-pool section of the affected version's guide says, "By default every request uses the active account only," then describes the enabled pool's selection and failover behavior. That section does not state the native-passthrough exception; the native authentication behavior is explained separately later in the guide.
Expected outcomes:
- Provide a clearly supported way for the enabled pool to govern genuine-Claude calls launched through OCX, with the effective selected account verifiable through a non-sensitive account label.
- When caller-native authentication is used instead, disclose at the pool controls and launch/request diagnostics that pool selection does not apply. Keep intentional native caller authentication available.
The exact configuration or UI design is a maintainer decision. These are requested outcomes, not claims that a changed routing path has already been validated.
Reproduction
Observed configuration and execution:
- Store two Anthropic OAuth accounts, A and B, in OpenCodex.
- Enable the Anthropic account pool, use
quota, set the threshold to 80, and select the five-hour window.
- Select Account A as Active in OpenCodex. The dashboard showed both accounts below the threshold when diagnosing the behavior.
- Leave the local Claude Code subscription login on Account B.
- Leave the entire
claudeCode configuration object absent, as in the affected installation.
- Start a new nonpersistent Claude Code invocation through the OCX launcher using a real Claude model, with no model-map or gateway alias.
The actual invocation had the following shape. Only local filenames have been replaced with generic names; empty-mcp.json contained {"mcpServers":{}}.
type input.txt | call ocx.cmd claude -p --model "claude-fable-5-1[1m]" --fallback-model "claude-fable-5-1[1m]" --effort xhigh --tools "" --strict-mcp-config --mcp-config empty-mcp.json --setting-sources "" --output-format json --no-session-persistence > result.json 2> stderr.txt
The original input was a private review request and is not attached. A short synthetic input can be used for a prospective reproduction, but that reduced-input reproduction has not been run. This report is based on an existing successful invocation and subsequent source/configuration inspection, not a new controlled A/B experiment.
Version
- Installed
@bitkyc08/opencodex: 2.42.0
- Claude Code: 2.1.261
- Behavior on newer releases has not been tested.
Operating system
Windows, version 25H2, build 26200.8875. Local proxy on loopback.
Provider and model
Configured provider: anthropic, adapter anthropic, authMode: "oauth".
CLI model: claude-fable-5-1[1m].
OpenCodex logged model: claude-fable-5-1.
OpenCodex logged provider: anthropic-native.
Logs or error output
The saved launcher script confirms that it invoked ocx.cmd claude -p. This was not an unwrapped direct Claude CLI call.
The saved CLI result reported is_error: false, num_turns: 1, and duration_ms: 379465. Two matching OCX usage records shared the same conversation key:
[
{"provider":"anthropic-native","model":"claude-fable-5-1","durationMs":7649},
{"provider":"anthropic-native","model":"claude-fable-5-1","durationMs":379319}
]For account attribution, a private local check reconstructed the conversation hash from the saved CLI session ID and the Claude Code metadata identity belonging to Account B; it matched those OCX records. The identity values and identifiers are omitted here. This establishes the caller identity used in the native route; it is not an independent measurement of subscription quota deltas or billed cost.
Screenshots and supporting files
Source-level explanation in the affected release:
Consequently, changing quota versus fill-first does not affect a request already taking this native branch.
Related reports reviewed:
I searched open and closed issues/PRs for nativePassthrough, anthropic-native, native passthrough plus pool, and Claude account pool, and did not find an issue covering this exact interaction.
Redacted configuration
Relevant excerpt only:
{
"anthropicAccountPool": {
"enabled": true,
"autoSwitchThreshold": 80,
"strategy": "quota",
"stickyLimit": 1,
"quotaWindow": "five-hour"
}
}The claudeCode object is absent. In this version, absence leaves native passthrough eligible: its guard disables the path only when nativePassthrough === false. No explicit native-passthrough override was configured.
Checks
Client or integration
Claude Code, launched through
ocx claude -pagainst a local OpenCodex proxy.Area
Authentication and account pool
Summary
With the Anthropic OAuth account pool enabled and Account A displayed as Active, a successful
ocx claude -prequest for a genuine Claude model used the Claude Code login belonging to Account B. OpenCodex recorded the request asanthropic-native.I understand that native passthrough intentionally preserves the caller's subscription credentials. The problem is the interaction with an explicitly enabled account pool: the dashboard's Active account and quota strategy do not govern these requests, without making that exception apparent in the pool controls. Users cannot rely on the pool settings to control which account their OCX-launched Claude work consumes.
The account-pool section of the affected version's guide says, "By default every request uses the active account only," then describes the enabled pool's selection and failover behavior. That section does not state the native-passthrough exception; the native authentication behavior is explained separately later in the guide.
Expected outcomes:
The exact configuration or UI design is a maintainer decision. These are requested outcomes, not claims that a changed routing path has already been validated.
Reproduction
Observed configuration and execution:
quota, set the threshold to 80, and select the five-hour window.claudeCodeconfiguration object absent, as in the affected installation.The actual invocation had the following shape. Only local filenames have been replaced with generic names;
empty-mcp.jsoncontained{"mcpServers":{}}.The original input was a private review request and is not attached. A short synthetic input can be used for a prospective reproduction, but that reduced-input reproduction has not been run. This report is based on an existing successful invocation and subsequent source/configuration inspection, not a new controlled A/B experiment.
Version
@bitkyc08/opencodex: 2.42.0Operating system
Windows, version 25H2, build 26200.8875. Local proxy on loopback.
Provider and model
Configured provider:
anthropic, adapteranthropic,authMode: "oauth".CLI model:
claude-fable-5-1[1m].OpenCodex logged model:
claude-fable-5-1.OpenCodex logged provider:
anthropic-native.Logs or error output
The saved launcher script confirms that it invoked
ocx.cmd claude -p. This was not an unwrapped direct Claude CLI call.The saved CLI result reported
is_error: false,num_turns: 1, andduration_ms: 379465. Two matching OCX usage records shared the same conversation key:[ {"provider":"anthropic-native","model":"claude-fable-5-1","durationMs":7649}, {"provider":"anthropic-native","model":"claude-fable-5-1","durationMs":379319} ]For account attribution, a private local check reconstructed the conversation hash from the saved CLI session ID and the Claude Code metadata identity belonging to Account B; it matched those OCX records. The identity values and identifiers are omitted here. This establishes the caller identity used in the native route; it is not an independent measurement of subscription quota deltas or billed cost.
Screenshots and supporting files
Source-level explanation in the affected release:
anthropicAccountPool.enabled.Consequently, changing quota versus fill-first does not affect a request already taking this native branch.
Related reports reviewed:
nativePassthrough: false; disabling passthrough has not been tested as a remedy in this report.I searched open and closed issues/PRs for
nativePassthrough,anthropic-native, native passthrough plus pool, and Claude account pool, and did not find an issue covering this exact interaction.Redacted configuration
Relevant excerpt only:
{ "anthropicAccountPool": { "enabled": true, "autoSwitchThreshold": 80, "strategy": "quota", "stickyLimit": 1, "quotaWindow": "five-hour" } }The
claudeCodeobject is absent. In this version, absence leaves native passthrough eligible: its guard disables the path only whennativePassthrough === false. No explicit native-passthrough override was configured.Checks