Claude should work when repo-local .claude settings make it available

[Donkijote]

[Feature]: Make Claude availability workspace-aware when .claude settings already work in the repo

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

I use Claude in repos where the Claude CLI works because the repo has .claude/settings.json or .claude/settings.local.json, instead of relying on the default global claude auth login flow.

In those repos, Claude can work correctly from the CLI because the SDK/CLI resolves user, project, and local settings from the active working directory. But T3 Code still treats Claude as unavailable if the global auth probe reports unauthenticated.

That creates a false negative:

• Claude works in the current repo
• T3 says Claude is unavailable

So today T3 cannot be used in some repo-scoped Claude setups even though the underlying Claude runtime is actually usable there.

Screenshots

Add the screenshots manually in the GitHub editor under the matching caption.

Before: Claude is shown as unavailable because the UI only reflects the global auth snapshot.

After: Claude becomes selectable in the same repo when workspace-local .claude settings are detected, and the picker shows the project-config-backed model label.

After: the project-config-backed Claude model can be selected and used successfully in the thread, which demonstrates that the workspace-local Claude configuration is being honored.

Proposed solution

Add project-aware Claude runtime detection based on the active workspace cwd.

If the current workspace contains .claude/settings.json or .claude/settings.local.json, T3 should probe Claude in that workspace context and treat a successful SDK initialization as ready/authenticated for that project, even if global claude auth status is unauthenticated.

In the UI, when Claude is available through workspace-local config, T3 should also offer a project-config-backed model option that lets the Claude SDK resolve the model from .claude settings instead of forcing a concrete model override from T3.

If the configured model can be determined safely, that option should be presented with a readable label instead of a raw slug.

The Settings page should also keep global Claude auth messaging separate from workspace-specific .claude availability, instead of mixing both ideas into one sentence.

Why this matters

This would let T3 work with the same Claude configuration that already works in the CLI, including ad hoc setups, custom backends, and company-managed environments that do not use the default global Claude login flow.

More importantly, it makes provider availability reflect the real runtime behavior of the active workspace instead of only a machine-wide auth status.

That broadens where T3 can be used without requiring users to reshape their Claude setup into one specific global convention. It makes the app more adaptable to real-world repos and should make it usable in a wider variety of projects and teams.

Smallest useful scope

For Claude only:

• detect workspace-local .claude/settings.json or .claude/settings.local.json for the active workspace
• add a project-aware runtime status check keyed by cwd
• allow Claude to be selected when that workspace-scoped runtime check succeeds
• expose a Project config model option that omits the explicit SDK model override
• optionally label that option from the configured Claude model when possible
• keep the Settings page's global auth message separate from any workspace note

Likely implementation areas

I already explored this locally, and the change appears to be reasonably contained.

The main places that would likely need changes are:

• apps/server/src/provider/Layers/ClaudeProvider.ts
  Add a workspace-aware Claude runtime probe keyed by cwd, detect .claude/settings.json or .claude/settings.local.json, and treat a successful zero-turn Claude SDK initialization as ready for that workspace.
• apps/server/src/provider/Layers/ProviderRegistry.ts
  Expose a provider runtime status path in addition to the existing global provider snapshot.
• apps/server/src/ws.ts
  Add a project-aware server RPC such as server.getProviderRuntimeStatus.
• packages/contracts/src/server.ts
• packages/contracts/src/rpc.ts
  Add the runtime-status input/output contract, including optional Claude workspace metadata such as whether project settings were detected.
• apps/server/src/provider/Layers/ClaudeAdapter.ts
  Support a Claude “project config” model sentinel that omits the explicit SDK model override, so .claude settings can decide the model.
• packages/contracts/src/model.ts
  Add the Claude project-config sentinel model id.
• apps/web/src/lib/providerReactQuery.ts
• apps/web/src/rpc/wsRpcClient.ts
  Query the workspace-aware provider runtime status for the active repo.
• apps/web/src/components/ChatView.tsx
  Use the active workspace cwd to substitute the runtime-aware Claude status for the global snapshot when the user is in a repo that has .claude settings.
• apps/web/src/composerDraftStore.ts
• apps/web/src/modelSelection.ts
  Make project config the default Claude model path when workspace Claude settings are active, unless the user explicitly chooses a concrete model.
• apps/web/src/components/settings/SettingsPanels.tsx
  Keep the normal global auth message, but show any workspace-specific .claude note separately instead of mixing both concepts into one sentence.

Implementation notes

The main behavior change does not require T3 to ingest Claude secrets or fully parse .claude config itself.

The safer approach is:

• keep the existing global provider snapshot for install/version/global auth reporting
• add a second Claude runtime check scoped to the active workspace cwd
• rely on the Claude SDK's existing settingSources behavior instead of copying .claude auth/config values into T3 settings
• only read minimal non-secret metadata if needed for display, such as the configured model name for a picker label

The core end-to-end path is:

1. The web client knows the active workspace root for the current thread/project.
2. The client asks the server for Claude runtime status for that cwd.
3. The server checks for .claude/settings.json or .claude/settings.local.json.
4. The server attempts a zero-turn Claude SDK initialization with cwd and settingSources.
5. If that succeeds, Claude is treated as ready for that workspace even if global claude auth status is unauthenticated.
6. When the user selects the workspace-backed Claude option, T3 omits the explicit model override and lets Claude resolve it from .claude.

That is the smallest change that seems to solve the mismatch without widening the scope into custom config parsing, secret handling, or Claude history import.

Alternatives considered

Today the main workaround is to use the Claude CLI directly instead of T3 in repos that rely on workspace-local .claude settings.

Another workaround would be to manually duplicate settings into a global Claude login or config path, but that defeats the purpose of repo-scoped configuration and is not viable in some environments.

Risks or tradeoffs

This adds a second level of Claude availability: global provider status and workspace-specific runtime status.

That is worth the complexity because Claude can legitimately be unavailable globally but usable in a specific repo once .claude settings are applied for that cwd.

T3 should still avoid parsing or copying secrets from .claude itself and should rely on the Claude SDK's existing settings resolution.

If T3 reads any .claude metadata for display, it should be limited to non-secret fields needed for UI labeling, such as the configured model name, and should never expose tokens, env values, base URLs, or API endpoints in the UI.

Examples or references

Related but not sufficient:

• [Bug]: Claude provider ignores ~/.claude/settings.json env, so proxy-backed Claude fails #1267
• [Bug]: Doesn't work with Claude models via LiteLLM #1225
• [Bug]: Claude code doesn't support AWS Bedrock usage #1257

The key gap is that settingSources support alone does not help if T3 still gates Claude on a global unauthenticated status before attempting a workspace-scoped Claude startup.

Contribution

• I would be open to helping implement this.

[mmurilo]

Assessment: #7039 identifies a real gap, and its Claude-first scope is the right starting point. Workspace-aware discovery and a project-config model option are useful. I would avoid introducing a separate Claude-only runtime-status path or treating workspace readiness as global authentication. The existing workspace provider catalog path is a better place: keep global auth separate, probe the active cwd using Claude’s native settings resolution, and refresh workspace metadata safely. I would also avoid making file presence the availability check or parsing secrets and provider configuration in T3.

[mmurilo]

We opened a broader proposal: Workspace-aware provider discovery and session routing. It expands #7039’s Claude-specific scope to OpenCode and the shared provider catalog, so discovery and the active session use the same workspace context. #7039 remains the concrete Claude-first case.