[Bug]: Claude --settings launch arg does not expand ~ (binaryPath does); relative paths resolve against the project #26631

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Closest reports: #15073 (closed; introduced the current behavior where T3 reads the --settings file and merges it beneath its own settings) and #25017 (text generation ignores --settings). Neither covers how the file path is resolved, which is this report.

Area

apps/server

Steps to reproduce

1. Settings -> Providers -> Claude: Binary path claude, Launch args --settings ~/.config/sfproxy/claude/settings.json (any existing settings JSON under the home directory works; ~/.claude/settings.json reproduces it too).
2. Open a project whose directory is not the home directory and start a Claude thread.
3. Send a message.

Variant: --settings .config/sfproxy/claude/settings.json (relative, no tilde) from the same project.

Expected behavior

~ resolves to the home directory, as it already does for the Binary path field of the same provider, and the settings file is read and merged.

A --settings value is meant to point at one user-level file that holds no secret (in our case a company proxy profile: apiKeyHelper, env.ANTHROPIC_BASE_URL, a modelPicker). The natural way to write that path for every user is ~/.... Because T3 reads the file itself (since #15073) instead of passing the flag to the CLI, this is T3's resolution, not the CLI's; the Claude CLI's own behaviour with ~ is irrelevant once T3 has taken over reading the file.

Secondary expectation: a relative path should be documented as relative to the project directory, or rejected with a message that says so; today the error only shows the path T3 tried.

Actual behavior

ClaudeSettingsLaunchArgError: "Claude could not read the --settings launch argument at /path/to/project/~/.config/sfproxy/claude/settings.json as a JSON object. Fix it in the Claude launch arguments, then send the message again."

The tilde is kept as a literal directory name under the project.

Code: apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, readClaudeLaunchArgSettings (main @ 9e09926, line 1665):

const filePath = input.path.resolve(input.cwd ?? ".", trimmed);

The same file already imports expandHomePath from @t3tools/provider-core/server/pathExpansion and applies it to config.binaryPath (line 11171), so one provider field expands ~ and the other does not. readClaudeAppendSystemPromptFile (line 1629) and the config-dir override (line 4269) resolve the same way and presumably share the gap.

Impact

Major degradation or frequent failure

(For a team rolling out a shared launch-args recipe, every user whose project is not under a path where the literal ~ exists hits the error on the first message; the workaround below is non-obvious.)

Version or commit

T3 Code (Beta) desktop 0.1.3; code read on main @ 9e09926

Environment

macOS 15, T3 Code desktop 0.1.3, Claude Code CLI 2.1.287, provider claudeAgent

Logs or stack traces

Claude could not read the --settings launch argument at /Users/<user>/Documents/<project>/~/.config/sfproxy/claude/settings.json as a JSON object. Fix it in the Claude launch arguments, then send the message again.

Workaround

Use the absolute path: --settings /Users/<user>/.config/sfproxy/claude/settings.json. Per-user, so it cannot be shared as a recipe; a wrapper script that execs claude --settings "$HOME/..." as the binary does not work either, because T3 appends its own --settings JSON and the CLI keeps only the last one.