Connections: share selected threads between T3 setups, with explicit access and work limits

[MGRAFF2006]

Use case

I want to connect T3 Code with people I know—friends, family or collaborators—and share a specific thread so it appears inside their own T3 Code. Today I can send a guest link through another messenger, or connect a client to an environment, but neither gives me a saved connection with selected incoming threads.

The broader idea is Connections: establish a connection once, then explicitly choose what access to share at thread, project or machine level. This should be general product language rather than a team/coworker feature. Accepting a connection alone grants no access.

Suggested first increment

• Explicit invitation and acceptance, with a saved connection that can be removed.
• Share selected threads with independent recipient grants. A second recipient must not replace the first recipient's access.
• An incoming “Shared with me” collection in web, desktop and mobile, with accept, decline and remove.
• Initially reuse guest behavior: read the thread and propose messages for the owner to send or dismiss. Permission to start work directly would be a separate, explicitly approved capability.
• Owners can revoke an individual share or disconnect someone. Revocation ends active access, including subsequent history and attachment requests; reconnecting cannot restore revoked access.

Project and machine access are broader future choices, not prerequisites for this first increment. Their permissions would need separate agreement. In particular, a project is not a filesystem/credential sandbox, so a project grant must not imply isolation T3 does not provide.

Connectivity

Keep authorization separate from the route: T3 Connect, reachable HTTPS or Tailscale. Tailscale supplies connectivity, not permission to see a thread. Connect could help discover connections and deliver invitations; private setups could explicitly pair receiving endpoints without a hosted directory.

I would like maintainer direction on account-based identity versus explicitly paired environments. The intention is to connect independently owned setups, preserving the single-tenant boundary described in the multi-user RFC response.

The owner remains authoritative and must be reachable for live viewing. This does not require cloud transcript storage or a new relay/proxy implementation.

Work allowances, including my own threads

A related need is controlling how far work can run beyond the effort I expected. This applies to my personal threads as well as work I explicitly allow through a shared resource.

Settings could provide defaults and project/thread limits for cumulative tokens, runtime, concurrent work or turns where the execution layer can actually enforce them. Broader owner limits must constrain narrower choices. Delegated children and retries count toward the same allowance, rather than creating a bypass.

Show consumption, warn before exhaustion, then stop admitting new work and interrupt active work while preserving progress. Clearly distinguish interruption requested from termination acknowledged. Continuing requires an explicit extension. Enforcement must survive client disconnection.

Delayed usage reporting can overshoot, so a reporting threshold must not be labelled a hard token/spending cap. Cost estimates also differ from enforceable billing limits. Unsupported required limits should be reported before launch. Resource allowances cannot automatically detect semantic scope creep; asking before expanding the objective is a separate checkpoint.

This part should coordinate with #32225, supported execution bounds, and can be scoped independently rather than bundled into a large sharing PR.

Existing pieces and related proposals

The checkout examined already has guest links, saved environment routes and agent-to-environment peer links. Guest links are temporary, single-recipient and tied to Connect; ordinary environment read access is broader than an individual thread. These are useful foundations, but not the incoming-thread workflow above.

• #24944: collaboration inside the app — related team status/chat idea.
• #31234: guest links without Connect — relevant transport independence.
• #32225: execution bounds — relevant enforcement foundation.

Direction requested

Would saved connections plus incoming, independently revocable thread shares be an acceptable first contribution? Should identity/delivery initially use Connect accounts, paired private endpoints, or both? Should work-allowance settings be developed separately on the execution-bounds proposal?

I am seeking direction and scope approval before implementation, as CONTRIBUTING.md requires. No implementation or maintainer approval is claimed.

Prepared with gpt-6.1-sol through the Codex harness in T3 Code.