Workspace-aware provider discovery and session routing

[mmurilo]

Related discussion: #7039: Claude should work when repo-local .claude settings make it available

This proposal expands #7039 beyond its Claude-specific scope to cover OpenCode and the shared provider catalog.

Problem

T3 currently has to combine two different kinds of provider state:

• Global state, such as whether a provider is installed, authenticated, or reachable on the machine.
• Workspace state, such as which native configuration, commands, skills, models, or agents apply to the active repository.

Those states are not interchangeable. A provider can be unavailable according to a global check but usable in one workspace because that workspace has provider-native project configuration. The reverse can also happen: a provider can be globally available while its project-specific configuration is invalid or its local runtime cannot serve the selected workspace.

This can make the provider picker inaccurate, make workspace-specific capabilities appear or disappear, and cause a session to run with a different working directory or configuration context from the one used to build the catalog.

Claude is the clearest current example, described in #7039. OpenCode has the same broader class of problem because project configuration, models, agents, and the directory used by a local or external server can affect what is actually available.

Proposal summary

Make provider discovery and session routing workspace-aware while keeping global provider state separate.

The active workspace should be the context used to discover the provider capabilities shown to the user. The same resolved workspace should then be used when starting or resuming the session, so the catalog and the running provider agree about the project they are serving.

The shared behavior should:

• Keep global installation, account, authentication, and usage information separate from workspace availability.
• Discover provider-native capabilities for the active workspace, including commands and skills, and models or agents where the provider supports them.
• Preserve the workspace context when creating, resuming, or switching threads, including worktrees and remote connections.
• Refresh workspace discovery when the workspace changes or the user explicitly requests a refresh.
• Avoid copying provider secrets or recreating provider configuration in T3 when the provider can resolve it natively.
• Fail clearly when a workspace cannot be served, without replacing a healthy previous catalog with partial data.

The implementation should start with the Claude case in #7039, then apply the same catalog and routing semantics to OpenCode. Provider-specific behavior should remain at each provider boundary rather than becoming a new generic configuration system.

Why this matters

Users expect the provider picker and the active session to reflect the repository they are working in. A machine-wide status check is not enough when provider behavior depends on the current directory.

Workspace-aware discovery would make native project configuration useful from T3 without forcing users to duplicate settings into a global T3 configuration. It would also make provider capabilities more predictable across web, desktop, mobile, local, and remote usage.

This is primarily a correctness and reliability improvement: the UI should not say a provider is unavailable when it works in the active workspace, and a session should not silently run under a different configuration context from the one the user selected.

Suggested scope

A focused first phase would define the shared workspace-aware behavior and implement it for Claude, using #7039 as the concrete acceptance case. A follow-up phase would extend the same behavior to OpenCode, including local and externally hosted server contexts.

This proposal does not require T3 to import provider configuration, expose secrets, or support every provider-specific setting. It also does not change the meaning of global authentication status. The goal is to make discovery and session routing agree about the active workspace, one provider at a time.

Open questions

• What should be the authoritative workspace when a project root, worktree, and provider server directory differ?
• How should workspace availability be shown without implying that global authentication has changed?
• Which provider capabilities belong in the shared catalog, and which should remain provider-specific?
• What should the user see when a workspace changes while an existing thread has an explicit model or agent selection?

The intended outcome is a small, shared concept with provider-specific implementations, starting from the concrete Claude problem in #7039 and avoiding a large cross-provider rewrite.

[mmurilo]

Proposal architecture

The core change is to treat the active workspace as an explicit input to both provider discovery and session startup, rather than using the machine-wide provider snapshot for everything.

1. Resolve one workspace context

When a thread is created, resumed, or switched, T3 should resolve the workspace context once. That context should identify the effective working directory, including worktrees, project roots, and remote connection constraints where applicable.

The same context must be used for:

• Discovering the provider capabilities shown in the catalog.
• Starting or resuming the provider session.
• Resolving workspace commands, skills, models, and agents.

This prevents the catalog from being built for one directory while the session runs in another.

2. Keep global and workspace state separate

The existing global provider state should continue to represent installation, version, account, authentication, and usage information for the environment.

Workspace discovery should be a separate, cached snapshot keyed by provider and workspace. It should describe whether that provider is usable in the workspace and which native capabilities apply there. Workspace availability must not overwrite or reinterpret global authentication.

3. Put provider-specific discovery at the adapter boundary

The shared provider registry should own the lifecycle of workspace snapshots, caching, refresh, and failure handling. Each provider adapter should own how it discovers its native workspace behavior.

For Claude, that means probing the active workspace through Claude’s normal settings resolution and exposing workspace-local capabilities without copying secrets or reimplementing the configuration system.

For OpenCode, that means resolving the project configuration, available models and agents, and the directory used by the local or externally hosted server. These details should remain OpenCode-specific rather than becoming generic T3 configuration parsing.

The shared catalog can expose common capability categories, while provider-specific metadata remains behind each adapter boundary.

4. Make refresh safe and explicit

Workspace snapshots should refresh when the active workspace changes and when the user explicitly requests a refresh. A successful refresh should replace the snapshot atomically. A failed or partial discovery should leave the last known good snapshot intact and expose the failure separately, rather than presenting an empty catalog.

This is important for remote connections and local provider servers, where discovery can fail temporarily or where the server may not be able to serve every requested directory.

5. Route sessions through the resolved workspace

Thread creation and recovery should preserve the workspace context that the user selected. Provider startup should receive that same context instead of independently choosing a fallback directory.

If the workspace is no longer available, T3 should report that mismatch clearly. It should not silently start the session in the project root or another directory while leaving the catalog unchanged.

6. Keep the client model simple

The client should consume global provider state and workspace provider state separately. It should not need a Claude-specific or OpenCode-specific status workaround in the chat UI.

Where a provider supports native project configuration, the model or agent picker should be able to represent “use the workspace configuration” without forcing T3 to send a concrete override. Existing explicit user selections should remain stable when the workspace changes.

Phased delivery

The first phase should implement the shared workspace snapshot and routing semantics for Claude, using #7039 as the concrete acceptance case. The second phase should apply the same architecture to OpenCode, including local and externally hosted server behavior.

This keeps the first change focused while establishing one provider catalog and session-routing model instead of adding separate status paths for each provider.