fix: prevent Anthropic-specific fields from leaking into 3P requests

[auriti]

Summary

Fixes 4 bugs where Anthropic-internal data was unconditionally included in requests to third-party OpenAI-compatible providers. All findings verified against the current codebase.

Root Causes

Finding	Severity	File	Root Cause
cache_control leak	HIGH	claude.ts:333	getPromptCachingEnabled() returns true for all providers — no provider check
Header forwarding	HIGH	client.ts:163	defaultHeaders (session IDs, x-anthropic-*, potentially Anthropic API key) passed directly to shim
Image data loss	HIGH	openaiShim.ts:186	Tool result content maps only text fields — image blocks produce empty strings
Resume tool corruption	MEDIUM	conversationRecovery.ts:186-196	stripThinkingBlocks runs after filterUnresolvedToolUses — removing a thinking-only message orphans its paired tool_result

Changes

File	Change
src/services/api/claude.ts	getPromptCachingEnabled() returns false for openai/gemini/github/codex providers
src/services/api/client.ts	Filter x-anthropic-*, x-claude-*, authorization, api-key headers before passing to shim
src/services/api/openaiShim.ts	Handle image blocks in tool result content — convert to [Image](url) placeholders (aligned with codexShim.ts)
src/utils/conversationRecovery.ts	Run stripThinkingBlocks before filterUnresolvedToolUses for 3P providers
src/services/api/openaiShim.test.ts	Regression test: image content in tool results preserved as placeholder

Issues addressed

• bug: Anthropic-specific fields leak into 3P provider requests #267 (all 4 findings)

Test plan

• bun test src/services/api/openaiShim.test.ts — 5/5 pass (includes new image regression test)
• bun test src/utils/context.test.ts — 6/6 pass
• Manual: verify no cache_control in 3P request payload
• Manual: verify no x-anthropic-* headers sent to 3P endpoint
• Manual: tool result with image content shows [Image](url) in conversation
• Manual: resume a 1P session against a 3P provider with thinking blocks

[gnanam1990]

Thanks for addressing this. I don't think the leakage problem is fully closed yet.

The fixes appear to cover the env-driven shim path, but there are still gaps for providerOverride-based routing. Those paths can still carry Anthropic-specific headers and fields because the filtering and cache-control guards are not consistently applied there too.

Please extend the fix to the providerOverride path and add focused tests covering header stripping and cache-control suppression on overridden third-party requests.

[auriti]

Thanks for the thorough review — you're right that the previous fix only covered the env-driven path in `client.ts`.

This follow-up commit extends the guard with defense-in-depth inside `openaiShim.ts` itself, so Anthropic-specific headers are stripped regardless of how the shim client is created:

• `filterAnthropicHeaders()` is now applied at `OpenAIShimMessages` construction time (covers any `defaultHeaders` passed directly to the shim)
• Same filter applied to per-request `options.headers` in both `_doOpenAIRequest` (OpenAI/Gemini/GitHub path) and the Codex `_doRequest` path
• Two new focused tests added:
  • Header stripping via direct shim creation — verifies `x-anthropic-`, `x-claude-`, etc. never reach the fetch call even when bypassing `client.ts`
  • Cache-control suppression — verifies `cache_control` blocks are not forwarded in the request body to OpenAI-compatible endpoints

All 7 tests pass.

[Vasanthdev2004]

fix conflicts @auriti

[auriti]

Conflicts are now resolved by merging the latest main into this branch.

I kept the leakage fix aligned with the current providerOverride flow in openaiShim.ts, and re-ran the focused src/services/api/openaiShim.test.ts suite plus bun run smoke successfully.

[Vasanthdev2004]

Rechecked the current head afc58c293c7b038c5da95a83b2d3e651a6f31980 against current origin/main.

The follow-up commits do close the earlier blocker from the old review thread:

• providerOverride-based routing now goes through the same Anthropic-header scrubber in openaiShim
• providerOverride requests also suppress cache_control
• the image tool-result regression is covered and passing

I still can't approve because Anthropic-specific headers can still leak through a real supported path.

1. src/services/api/client.ts:110-122, 389-412 plus src/services/api/openaiShim.ts:95-110
ANTHROPIC_CUSTOM_HEADERS is merged directly into defaultHeaders in client.ts. The new scrubber in openaiShim.ts only removes:

   • x-anthropic*
   • x-claude*
   • auth headers (authorization, x-api-key, api-key)

   It does not remove canonical Anthropic headers like:

   • anthropic-version
   • anthropic-beta

   Direct repro I verified locally on this head:

   • create the shim with defaultHeaders containing:
     • anthropic-version: 2023-06-01
     • anthropic-beta: prompt-caching-2024-07-31
   • send a normal 3P OpenAI-compatible request
   • the outbound request still contains both headers unchanged

   This matters in the real client path because ANTHROPIC_CUSTOM_HEADERS is parsed into defaultHeaders before routing (client.ts:110-122). So the branch still does not fully satisfy its own goal of preventing Anthropic-specific fields from leaking into third-party requests.

Non-blocking note:

• src/utils/conversationRecovery.ts changes the 3P resume preprocessing order, but there is still no targeted regression test for the thinking/tool_result pairing case described in the new comment.

What I verified on this head:

• bun test src/services/api/openaiShim.test.ts src/utils/context.test.ts -> 40 pass
• bun run test:provider -> 141 pass
• bun run build -> success
• bun run smoke -> success
• direct runtime repro that providerOverride strips x-anthropic-* headers and suppresses cache_control
• direct runtime repro that anthropic-version and anthropic-beta still reach the third-party request

I would not merge this until canonical Anthropic headers are scrubbed too, not just the x-anthropic* variants.

[auriti]

Addressed the remaining header-leak path.

This follow-up now strips canonical Anthropic headers in addition to the existing x-anthropic-* / x-claude-* scrubber:

• anthropic-version
• anthropic-beta

Applied in both places that matter for 3P routing:

• src/services/api/client.ts
• src/services/api/openaiShim.ts

I also extended the focused shim test so both headers are asserted to be removed from:

• shim defaultHeaders
• per-request options.headers

Local validation:

• bun test src/services/api/openaiShim.test.ts -> 34 pass, 0 fail

This should close the remaining leakage case called out in review where ANTHROPIC_CUSTOM_HEADERS could still forward canonical Anthropic headers to third-party OpenAI-compatible endpoints.

[auriti]

Rebased/updated the branch with the latest main and resolved the merge conflict around conversationRecovery.ts.

The canonical header scrubber follow-up is still included on top of current main:

• anthropic-version
• anthropic-beta

Current branch head also keeps the earlier providerOverride/cache-control coverage. The focused shim test still covers the canonical-header case that prompted the latest review round.

If there are no new issues on the updated head, this should be ready for a fresh re-review.

[Vasanthdev2004]

Targeted maintainer triage review of the current head ($short).

Verdict: Needs changes

Blocking issue:

1. GitHub reports this branch as DIRTY / conflicting with main, so it cannot be merged or final-approved as-is. Please rebase or merge latest main, resolve the conflicts, and rerun the relevant checks.

I did not do a full code review because the current branch state is not mergeable. Happy to re-review once the branch is clean.

[jatmn]

Thanks for following up on the earlier review. The providerOverride/cache-control coverage looks addressed now, and the canonical Anthropic header scrubber covers anthropic-version / anthropic-beta in the shim tests. I found one remaining blocker below.

Findings

• [P1] Remove the duplicate provider declarations so the branch builds
  src/utils/conversationRecovery.ts:242
  This block adds const provider and const isThirdPartyProvider in the same deserializeMessagesWithInterruptDetection scope where the existing thinking-strip block already declares both again at lines 263-264. Bun rejects the file with "provider" has already been declared, so bun run build fails and the focused test command cannot complete. Please reuse the existing provider variables, rename/scope the new ones, or consolidate the two third-party-provider checks before merge.

Recommendation: request changes.

[jatmn]

Thanks for following up here. I rechecked the current head against current main, and I still cannot approve this as-is.

Findings

• [P1] Resolve the branch conflicts with current main
  src/services/api/openaiShim.ts
  GitHub currently reports the PR as dirty/not mergeable, and a local merge attempt against current origin/main conflicts in src/services/api/openaiShim.ts and src/services/api/openaiShim.test.ts. The conflicts are around the header-scrubbing code and the adjacent OpenAI shim regression tests, so this branch cannot be merged or safely final-reviewed until it is rebased/merged onto current main and the focused checks are rerun.

• [P1] Remove the duplicate provider declarations so the branch builds
  src/utils/conversationRecovery.ts:242
  This head still declares const provider and const isThirdPartyProvider at lines 242-243, then declares the same names again in the same deserializeMessagesWithInterruptDetection scope at lines 263-264. Bun rejects the file with "provider" has already been declared, so bun run build fails and the focused test command also errors when it imports this module. Please consolidate/reuse the provider variables, or scope/rename one of the checks, before merge.

[jatmn]

closing as abandoned