Caller-owned thread_spawn preview still reads physical main auth.json #4850

Client or integration

Codex App

Area

Authentication and account pool

Summary

A thread_spawn request that authenticates with the caller's own forwardable Codex bearer still opens the operator's physical native-main auth.json during request preview.

The native-main read fence already prevents quota priming, entitlement discovery, denial-cache credential validation, reconciliation, and final-auth selection from reading physical main for this credential domain. Pool eligibility remains outside that fence:

1. prepareResponsesRequest calls previewCodexAccountForRequest.
2. Priority preemption reaches getEligiblePoolAccounts.
3. Main eligibility calls isMainAccountCredentialUsable, which opens and parses auth.json.
4. applySubagentModelFallback invokes the preview callback and repeats the same read.

Final authentication does not select or send the physical main credential: it uses synthetic liveness and either selects a stored pool account or preserves the caller-owned credential. The preview can nevertheless score physical-main liveness, cached quota, and plan state and use that result when deciding whether to rewrite the subagent model.

Expected: a request authenticated with its own credential performs no physical-main credential reads or scoring.

Actual: request preview reads auth.json twice through pool eligibility.

Severity is bounded. There is no token disclosure, refresh, upstream send, or quota consumption through the observed path, and the credential-substitution hypothesis was checked and falsified. The observable consequence is that operator-main state can influence subagent model selection for a request that owns its own credential.

ADR-0086 records "read the physical main token for identity" as an explicitly rejected alternative, and #4813 states that caller-owned preview "could read the physical main token and score main differently from final authentication" — so this path being outside the fence appears to be an omission rather than a decision.

Reproduction

1. Configure canonical OpenAI forwarding in Pool mode with:

   • a physical native-main auth.json;
   • one usable stored pool account;
   • a subagent fallback chain.

2. Send a /v1/responses thread_spawn request carrying a forwardable caller Codex bearer.

3. Instrument fs.readFileSync calls whose path ends in auth.json.

4. Observe these two stacks before final dispatch:

   • prepareResponsesRequest -> previewCodexAccountForRequest -> pickPriorityPreemption -> getEligiblePoolAccounts -> isCodexAccountUsable -> isMainAccountCredentialUsable
   • applySubagentModelFallback -> poolAccountPreview -> previewCodexAccountForRequest -> ... -> isMainAccountCredentialUsable

5. Observe that final authentication still dispatches with the stored pool account or caller-owned bearer rather than the physical main credential.

The behavioural test at tests/responses/responses-preview-main-read-fence.test.ts records these reads; its denial-cache assertions deliberately filter them out because closing pool-liveness was outside that test-only change.

Version

d6ebcc8

Operating system

Observed in hosted GitHub Actions while converting the read-fence source contract to behavioural assertions. The call path is platform-independent.

Provider and model

openai / gpt-5.6-sol

Logs or error output

prepareResponsesRequest
  previewCodexAccountForRequest
  pickPriorityPreemption
  getEligiblePoolAccounts
  isCodexAccountUsable
  isMainAccountCredentialUsable
  readFileSync(.../auth.json)

applySubagentModelFallback
  poolAccountPreview
  previewCodexAccountForRequest
  pickPriorityPreemption
  getEligiblePoolAccounts
  isCodexAccountUsable
  isMainAccountCredentialUsable
  readFileSync(.../auth.json)

Screenshots and supporting files

The behavioural evidence is in tests/responses/responses-preview-main-read-fence.test.ts.

A narrow fix exists: use the existing CodexAccountUsabilityOptions.isMainAccountTokenLive seam in both request-preview option objects, returning read-free synthetic liveness for caller-owned requests and preserving the documented healthy main-pin behaviour from #3166. Scoping it to previewRequestScopedMainCredential === true leaves ordinary request selection unchanged.

Redacted configuration

{
  "defaultProvider": "openai",
  "activeCodexAccountId": "pool-a",
  "autoSwitchThreshold": 0,
  "subagentModelFallback": ["xai/example-fallback"],
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "authMode": "forward",
      "codexAccountMode": "pool"
    }
  },
  "codexAccounts": [
    { "id": "__main__", "isMain": true },
    { "id": "pool-a", "isMain": false }
  ]
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.