Proposal: expose thread-aware process launch and disposal hooks

[Dropje97]

Problem

T3 has authoritative knowledge of which provider sessions and terminal PTYs belong to a thread, but that ownership is currently internal to the server.

Hosts that want stronger process lifecycle or resource isolation cannot reliably reconstruct that relationship after a process has started. PID ancestry, persisted-state polling, log observation, and timing assumptions all introduce races, and they do not reliably cover detached or reparented descendants.

This also makes it difficult for a host to distinguish session-local work from processes that were intentionally made durable.

Proposed seam

Would T3 be open to a small, optional process-boundary integration with two capabilities?

1. Thread-aware process launch interception

Before starting a provider process or T3-managed terminal PTY, T3 would expose a launch interception point containing authoritative context such as:

• environmentId
• threadId
• process kind, such as provider or terminal
• terminal ID where applicable
• executable and argv
• cwd, environment, and other launch context required to preserve existing behavior

The integration could arrange for the child to be launched through an external process boundary while T3 retains its existing provider and PTY I/O semantics.

The important property is that authoritative thread ownership is available before the child exists. A spawn-then-discover API would retain the race this proposal is intended to remove.

The exact configuration and API shape could be decided separately; this does not need to prescribe shell wrappers, systemd, or another particular process manager.

2. Guarded thread disposal

When settlement triggers T3's session cleanup, an optional disposal integration would run only after T3 has accepted the existing guarded cleanup operation:

1. provider-native cleanup runs, when a provider session exists;
2. T3 closes the thread's managed terminal PTYs;
3. the external integration is asked to dispose any remaining session-local descendants.

The disposal decision should remain downstream of T3's existing onlyIfSettled re-engagement guard rather than reacting independently to a raw thread.settled event. It should also cover a settled thread that has PTYs but no live provider session.

Launch and disposal calls need either serialization or an opaque lifecycle-generation identifier so delayed cleanup for an older session boundary cannot target a thread that has already resumed. A resumed thread would simply receive a fresh external boundary.

The disposal operation should be idempotent. Archive and delete could potentially reuse it where appropriate.

When no integration is configured, T3 would behave exactly as it does today.

Why external?

T3 does not need to contain platform-specific logic for systemd, cgroups, containers, job runners, or schedulers.

I validated the proposed boundary with an external per-thread systemd/cgroup prototype. Once launches received authoritative thread ownership before spawn, it could contain provider and PTY process trees, including detached or reparented descendants, Chromium/Playwright, GUI applications, development servers, and recordings. Settling one thread then removed its remaining session-local descendants without affecting concurrent threads.

That implementation is only evidence that the seam is sufficient; I am not proposing that its systemd-specific code become part of T3.

The same seam could support container hosts, remote agent runners, schedulers, sandbox managers, and other lifecycle or resource-control systems.

Scope

I am intentionally not proposing:

• a T3-specific resource-limit UI;
• systemd or cgroup support inside T3;
• a general extension or service-management framework;
• killing processes when an individual turn completes;
• changing the meaning of thread settlement;
• making intentionally durable services T3's responsibility.

The goal is only to expose enough authoritative process ownership and guarded lifecycle information for a host environment to implement a safe process boundary.

If this direction fits T3's architecture, I can share the small prototype diff and focused compatibility results that were used to validate the seam.

[Anejz]

+1, with a concrete use case: one cloud VM per thread.

We prototyped this without changing T3, using only a provider binaryPath wrapper for Claude and Codex. The first time the provider launches in a worktree, the wrapper creates a VM (Boat) from a snapshot, pushes the worktree's commit, and starts a two-way file sync between the local worktree and the VM. After that it runs claude / codex app-server on the VM over SSH. The Claude stream-json and Codex app-server JSON-RPC traffic goes over SSH unchanged. In our tests both providers ran turns on the VM, and edits synced back so T3's local diff/git flow kept working.

Everything the wrapper can't do cleanly maps directly onto this proposal:

1. Launch interception with threadId. The wrapper has to infer the thread from the launch cwd. That only works for worktree threads; local-mode threads share one checkout and would share a VM. It also has to rewrite local paths in argv. Authoritative {environmentId, threadId, kind, argv, cwd, env} before spawn is exactly what's missing.
2. Guarded disposal. Right now we garbage-collect VMs whose worktree directory is gone. A disposal call downstream of the onlyIfSettled guard, plus a lifecycle generation for resumed threads, would let us stop or delete the VM at the right time and never race a resumed thread.
3. Terminal PTYs. Only provider processes go through binaryPath, so T3-managed terminals still run locally while the agent works on the VM. A kind: terminal launch through the same seam would let the thread's terminal live on its VM too.

One thing worth keeping in the API shape: a remote boundary can take a while to become ready on first launch (tens of seconds to create a VM and sync), so it would help if the launch integration can prepare asynchronously before the provider starts.