Uh oh!
There was an error while loading. Please reload this page.
fix(claude): load Claude SDK filesystem setting sources - #1334
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
juliusmarminge
commented
Mar 23, 2026
perfect, this also makes it so user installed skills are loaded! thnak you   |
Uh oh!
There was an error while loading. Please reload this page.
Cherry-picked from pingdotgg/t3code@2b6640af. Adds settingSources: ["user", "project", "local"] to Claude SDK createQuery so it loads CLAUDE.md, project settings, and local config from the filesystem. Original author: Harshit Agarwal
Cherry-picked from pingdotgg/t3code@2b6640af. Adds settingSources: ["user", "project", "local"] to Claude SDK createQuery so it loads CLAUDE.md, project settings, and local config from the filesystem. Original author: Harshit Agarwal
Fixes#1267
Refs #1257
What Changed
Claude session startup now passes
settingSources: ["user", "project", "local"]to the Anthropic SDK inClaudeAdapter.That tells the SDK to load Claude Code's normal filesystem-backed settings when T3 launches a Claude session, instead of only relying on the options T3 passes directly.
I kept this intentionally small:
Why
This came out of two bug reports:
~/.claude/settings.jsonenv, so proxy-backed Claude failsThe common pattern in both reports is: Claude works fine in the CLI on the same machine, but Claude launched through T3 misses config that normally comes from Claude's settings files.
Auth is the most obvious failure mode.
In my own setup, I use Claude via API config in
~/.claude/settings.json, and at work that meant Claude worked normally in the CLI but T3-backed Claude sessions did not. The practical symptom looks like auth/login trouble because the Claude session T3 starts is missing settings that the normal Claude CLI session sees.After auth, this also affects the broader class of Claude filesystem settings, including
env-backed provider configuration. That lines up with the Bedrock / alternate provider reports too: if the Claude session launched by T3 does not load the same Claude settings sources as the CLI, you can end up with a session that behaves like it is using the wrong auth/provider path.The reason I took this approach instead of adding T3-side parsing is that Anthropic's SDK already exposes the setting source mechanism directly:
So this patch just opts T3 into the SDK's documented settings-loading path rather than re-implementing Claude's config resolution in app code.
Manual validation
I manually tested this against a few different real-world Claude setups:
~/.claude/settings.jsonto use a corporate Anthropic API proxy~/.claude/settings.jsonI also tried different permutations of Claude settings sources/files while checking the same basic behavior each time: if Claude already worked in the CLI on that machine, T3-backed Claude sessions should pick up the same config path instead of failing because auth/provider settings were missing.
Checklist
Note
Load Claude SDK filesystem setting sources for all sessions
Adds a
CLAUDE_SETTING_SOURCESconstant (['user', 'project', 'local']) in ClaudeAdapter.ts and passes it assettingSourcesin the options for every Claude SDK query session. This applies regardless of permission mode, including both full-access and approval-required runtime policies.Macroscope summarized 2c07b51.