Multi-user self-hosted environments with isolated execution

[LegandaryRa]

Would T3 eventually consider supporting shared self-hosted environments where multiple users can connect to the same environment while keeping their execution and credentials isolated?

This is specifically about multiple human users sharing one environment with separate execution/credential contexts, rather than multiple provider accounts, multiple environments, or sandboxed environments for a single user.

The important part would not just be identifying different users. Work started by one user should run in that user’s own execution context, including their:

• Codex / Claude / other provider subscriptions
• Git / GitHub / Forgejo credentials
• SSH keys
• MCP authentication
• CLI credentials and configuration
• filesystem/environment context

Conceptually:

User
↓
T3 environment session
↓
user-specific execution context
↓
Codex / Claude / OpenCode / shell / tools

The implementation could use OS users, workers, containers, or another isolation mechanism. The important property is that users do not implicitly share credentials or process identity.

Projects could then have simple membership, so one T3 environment could serve a small team while still keeping execution attributable and isolated.

OIDC could eventually be one way of establishing the user identity, but it does not need to be the core of this proposal. Pairing or other authentication mechanisms could coexist.

This seems like a substantial change from T3’s current “your machine, your agents” model, so the main question is:

Is multi-user self-hosting with per-user execution contexts something that fits T3’s longer-term direction, or is the environment intentionally expected to remain a single-user boundary?

[razzeee]

This is close to what I'm looking for. I'd like one self-hosted T3 server to act as a gateway for several people, with shared projects and agent sessions, while each person brings their own provider logins and chooses from the models available to them.

The shared sessions are important to me. I'd like colleagues to be able to open the same thread, see its history and live progress, and collaborate without copying conversations between separate T3 installations.

Sharing access to a project or thread shouldn't automatically give someone access to another person's provider account. It should be clear whose account is running the agent. How someone continues a shared thread using their own account would need an explicit design, especially when the provider can't resume the same session under a different login.

I came across Microsoft's Agent Host Protocol while looking into this. Its multi-client session synchronization seems relevant, though per-user credentials and project access would still need to be handled by T3.

Would shared projects and collaborative sessions fit the multi-user setup proposed here?

[v3rm0n]

I think even the credential isolation part is not needed when it would be possible to run a lightweight version of the T3 server per user that knows how to orchestrate the execution sessions on different machines.

[fadymondy]

Adding the "share one live session" use case, as #17196 was folded in here. In OmniAgent (by Data Breaks) we use a share link per session: a teammate opens it, sees the history and the live run, and can act on that one session (send messages, answer approvals). The link grants nothing else on the server: no other threads or projects, and no access to the owner's provider accounts. The owner can revoke it.

For T3, the smallest version consistent with this discussion would be a revocable, thread-scoped access grant on top of the existing pairing/auth, so the guest acts on that thread only. Agent work keeps running under the host's credentials, as it does today, until the per-user execution contexts proposed above exist.

I'd be glad to help prototype that piece if maintainers want to scope it.

[Morriz]

Related: we opened #27974 for the smaller first step every variant here needs: several people signing in to one environment as themselves, with each message recorded under the person who sent it. No isolation, just identity. If it lands, isolation can build on it.