From Prompt to Durable Work: Threads, Permissions, and Worktrees

T3 Code’s main user-facing unit is not a single prompt and not a provider process. It is the thread: a durable record of conversation and work that connects a project, a workspace choice, a permission policy, and the changing status of an agent task. This chapter follows that thread from creation through active work, interruption, settlement, and return. The goal is to show what users can control directly, what the environment keeps alive, and why a permission mode is a policy boundary rather than a universal sandbox.

A thread is a work unit, not a transcript

A transcript records what someone said. A T3 Code thread records a longer relationship between a person, an agent, and a workspace. It can retain the conversation and work history after a provider process exits. It can be attached to a project checkout or to a separate Git worktree. It has a runtime policy, status, and organizational position in the client. Those properties answer questions a transcript cannot: which files should this work touch, can another message steer it now, is it waiting for a person, and should it remain among active work?

The environment owns that lifecycle. A client can display a thread as active, pinned, snoozed, settled, or archived, but clients do not independently decide that an idle task is finished. The server evaluates the state it has persisted, including ongoing work, approvals, questions, and background activity. This matters when the user changes devices. A phone can close while the environment continues to track the thread; a desktop can reopen later and receive the server’s result instead of reconstructing the status from its own clock.

Thread creation and provider execution are also separable. A user can create a new thread before the provider process is ready, select a project or machine, and then send a message. The first turn starts the provider work that the thread records. This separation makes the thread a durable application object rather than a thin wrapper around a currently running process. A provider can exit without deleting the thread, and a later action can decide whether to resume the native session or start a replacement path.

A thread can also be a place where the user manages parallel work. A new worktree gives a thread a separate Git checkout and branch context rather than putting every agent turn into the project’s main checkout. This does not solve every concurrency problem—two worktrees can still operate on related code, and shared services can still conflict—but it establishes a clearer filesystem and version-control boundary for independent changes. The choice is about protecting the meaning of a thread’s changes, not about creating a second environment.

That distinction helps with a common real-world sequence. One thread may ask an agent to investigate a bug, while another tries a proposed fix. If both operate in the main checkout, the second agent can see or alter the first agent’s unfinished files, making the conversations difficult to compare. With separate worktrees, each thread has a clearer starting point and its own branch context. The environment still owns both worktrees, but the thread-to-checkout relationship gives the user a way to attribute changes and discard one line of exploration without erasing the other.

The separation is not only about files.