Describe the feature
Two small additions to @tanstack/ai-claude-code (0.3.2) that we currently carry as a pnpm patch:
1. Expose Claude Code's first-party --setting-sources flag.
ClaudeCodeTextConfig has no way to control which filesystem setting sources the CLI loads, so a server-side deployment cannot exclude user-level settings/Skills from a run. The CLI already supports it; the adapter only needs to forward it:
export type ClaudeCodeSettingSource = 'user' | 'project' | 'local';
// ClaudeCodeTextConfig:
settingSources?: Array<ClaudeCodeSettingSource>;
if (config.settingSources !== void 0)
args.push("--setting-sources", q(config.settingSources.join(",")));2. Forward the init message's Skill list on the existing session metadata event.
The CLI's init message reports the loaded Skills, but the adapter drops the field, so an application cannot distinguish configured, discovered, and invoked Skills without parsing Claude's private transcript format. The session metadata CUSTOM event already carries sessionId/model/tools; adding the field is one line:
value: {
sessionId: sdkMessage.session_id,
model: sdkMessage.model,
tools: sdkMessage.tools,
skills: sdkMessage.skills ?? [],
}plus skills?: Array<string> on the init message type.
Our use case: a production agent that ships its own project-scoped Skills and needs to (a) guarantee no user-level Skills leak into runs and (b) verify, per run, that the expected Skills actually loaded (a Skill that fails to load is silent otherwise).
Happy to open a PR for both.
Platform
@tanstack/ai-claude-code 0.3.2
Describe the feature
Two small additions to
@tanstack/ai-claude-code(0.3.2) that we currently carry as a pnpm patch:1. Expose Claude Code's first-party
--setting-sourcesflag.ClaudeCodeTextConfighas no way to control which filesystem setting sources the CLI loads, so a server-side deployment cannot exclude user-level settings/Skills from a run. The CLI already supports it; the adapter only needs to forward it:2. Forward the init message's Skill list on the existing session metadata event.
The CLI's init message reports the loaded Skills, but the adapter drops the field, so an application cannot distinguish configured, discovered, and invoked Skills without parsing Claude's private transcript format. The session metadata CUSTOM event already carries
sessionId/model/tools; adding the field is one line:plus
skills?: Array<string>on the init message type.Our use case: a production agent that ships its own project-scoped Skills and needs to (a) guarantee no user-level Skills leak into runs and (b) verify, per run, that the expected Skills actually loaded (a Skill that fails to load is silent otherwise).
Happy to open a PR for both.
Platform
@tanstack/ai-claude-code 0.3.2