[Feature]: Model unsent drafts as real threads in a draft state, shown in Sidebar V2

[Jardo-51]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

I often know what I want an agent to do next, but can't start it right now — a turn is already running in that project, I'm out of usage for the window, the task depends on something that isn't merged yet, or I want to think about the wording before spending a run.

Today an unsent draft is invisible, singular, and local:

• Invisible. A draft does not appear anywhere in Sidebar V2. It exists only inside the composer of whatever route I'm on, so navigating away leaves no reminder that a prompt is sitting there, and no way to see at a glance which projects have pending work.
• Singular. There is at most one draft per project — composerDraftStore exposes getDraftThreadByProjectRef(projectRef) — and "new thread" reuses that project's existing draft rather than creating another. I can't line up two or three prompts for the same repo.
• Local. Drafts live in localStorage under a ~5MB origin-wide quota shared with the prompt stash, and never leave the browser profile that created them.

The net effect is that there's no way to build up a short list of "tasks I want to run in this project, but not yet."

Proposed solution

Make a draft an actual thread that hasn't taken its first turn yet, rather than a client-side record that becomes a thread at send time.

The pieces for this already exist and are already separated correctly:

• thread.create is a standalone command whose decider (apps/server/src/orchestration/decider.ts) does nothing but check that the project exists and the thread ID is unused, then emit thread.created. It has no filesystem or git side effects.
• Worktree preparation and setup scripts are separate bootstrap steps, sequenced after thread.create inside the turn-start handler in apps/server/src/ws.ts (prepareWorktree, runSetupScript).
• The client already allocates the thread's aggregate ID when the draft is created; it just holds it locally and defers thread.create into thread.turn.start's bootstrap.createThread at send time.

So the change is: dispatch thread.create when the draft is started, instead of deferring it to send. Environment materialization stays exactly where it is — on the first turn — so a draft thread costs nothing but a row.

Everything else follows from that:

1. Drafts appear in Sidebar V2 automatically, because they are threads. They need a status label: resolveSidebarV2Status (apps/web/src/components/Sidebar.logic.ts) currently returns ready when a thread has no session, so it needs a branch returning draft for a thread that has never had a turn, and SidebarV2.tsx's topStatus block needs a corresponding Draft label in the slot that shows Working / Approval / Input / Failed / Woke / Done.
2. Multiple drafts per project become free. Threads are already many-per-project. "New thread" creates another draft thread; the one-draft-per-project mapping in composerDraftStore goes away rather than being generalized.
3. Drafts persist server-side and sync across clients, because thread state already does. The same pending list shows up in the desktop app, the web client, and mobile.
4. The localStorage quota problem disappears, and draft images can use the existing server attachment store — which is keyed by thread id (createAttachmentId(threadId) in apps/server/src/attachmentStore.ts), so a draft thread fits it directly, where a DraftId does not.

Two gaps this does not close for free, and which are the real work:

• The unsent prompt text needs a home. Thread content today arrives as a message on thread.turn.start; an unsent prompt is not a message yet. This needs a small addition — a thread.draft.set command and event carrying text plus attachment references, and a column on the thread projection to hold it. This is the one genuinely new piece of persistence.
• title is a required TrimmedNonEmptyString on thread.create, but a draft has no title until it's sent (today the title is derived from titleSeed at send). Drafts need either a nullable title or an explicit placeholder that the sidebar renders as the draft's prompt text.

Why this matters

It closes the gap between "I thought of a task" and "I ran the task" without leaving the app or holding it in my head — specifically when the reason you can't run it right now is temporary: a turn is already in flight, you've hit a usage limit and want everything queued for the reset, the task depends on a review or merge that hasn't landed, or you're switching between repos and want each one's next step visible where you already look.

Modeling drafts as threads also removes a class of bug rather than adding one. #4647 is caused precisely by the current split: the client holds a pre-allocated thread ID, defers thread.create to send, and when bootstrap fails and emits thread.deleted, the persisted draft keeps retrying thread.create against a tombstoned aggregate ID — permanently, across restarts. If the thread is created when the draft is created, there is no create-at-send-time step to retry against a dead ID, and bootstrap failure becomes an ordinary retryable turn failure on a thread that already exists.

It also makes the existing draft feature discoverable. Right now a draft you left behind is silently invisible until you happen to return to the same route, which is a small but real way to lose written work.

Smallest useful scope

Create the thread at draft time, add a draft status to resolveSidebarV2Status, and render a Draft label in Sidebar V2 — with the draft's prompt text still held client-side, exactly as it is now.

That alone makes pending work visible, and makes multiple drafts per project fall out, because they are threads. Server-side draft text (thread.draft.set) is a second step that adds cross-device sync and removes the quota ceiling, and can land separately.

Alternatives considered

• Keep drafts client-side and just render them in the sidebar. Less server work, and a draft stays editable when the server is unreachable. But it keeps the ~5MB shared quota, keeps the list pinned to one browser profile, requires generalizing the per-project draft mapping to a list by hand, needs a parallel "draft row" concept in a sidebar that otherwise renders threads, cannot reuse the thread-keyed attachment store, and leaves [Bug]: Failed bootstrap leaves new-thread draft pinned to a deleted thread ID #4647's tombstoned-ID path in place.
• A dedicated server-side draft table, separate from threads. Removes the quota and sync problems but duplicates a lot of what threads already provide — per-project grouping, attachments, environment and model selection, ordering, deletion — and still needs a second row type in the sidebar. Modeling drafts as threads reuses all of it.
• The prompt stash (shipped) is the closest existing feature: up to 20 provider-agnostic prompts with images, restorable into any thread. It doesn't solve this — stashed prompts live in a composer menu rather than the sidebar, the stash is one flat global list rather than per-project, and restoring deliberately drops the provider and model selection, which is right for its "move this prompt elsewhere" purpose but wrong for "this task is ready to run as configured."
• [Feature]: To-Do List & Queue/Steer Messages #4550 (To-Do List & Queue/Steer Messages) asks for a per-project to-do popup — an overlapping problem solved with a new surface holding free-text notes. This is narrower and reuses threads, so every entry is directly runnable rather than a note to retype.
• [Feature]: Scheduled Prompts #3624 (Scheduled Prompts) covers "run this later" via a timestamp, scoped to existing threads and explicitly excluding new threads. Good when you know when; this is for when you only know what.
• Queued follow-ups ([Feature]: Queue follow-up messages while the agent is running #5507, feat: add Steer and Queue follow-up modes alongside Chat/Plan #231) apply to a turn currently running in one thread. These drafts aren't attached to a live turn and generally target separate new threads.

Risks or tradeoffs

• Abandoned drafts become real rows in the event store. Every started-and-forgotten draft is now a thread.created event and a projection row, where today it's a localStorage entry that gets overwritten. Creating the thread only once the composer is non-empty avoids the worst of it, but some cleanup story — auto-delete of empty draft threads after N days, or a bulk clear — is probably needed rather than optional.
• Write amplification on draft text. The prompt changes on every keystroke. If thread.draft.set is dispatched per change it becomes an RPC and a SQLite write per debounce interval per client, and if it's an event-sourced event it also accumulates in the event log. [Bug]: Per-chunk assistant persistence causes progressive live output lag and rapid SQLite growth #5110 tracks an existing case of this shape (per-chunk persistence causing progressive lag and rapid SQLite growth). Draft text should be coalesced, debounced, and probably flushed on blur or navigation — and it may be a case for a mutable projection column updated in place rather than an event per edit.
• A draft status must not leak into places that assume a live thread. Anything iterating threads — filters, counts, "needs review" style prioritization ([Feature]: Prioritize Sidebar V2 threads that need review #4695), mobile thread lists, notifications — will start seeing threads with no session and no turns. Draft threads should be excluded from attention/unread treatment by default, since they're waiting on the user, not the agent.
• Sync introduces conflicts. Once draft text is server-side, two clients editing one draft need a resolution rule. Last-write-wins on an updatedAt is likely sufficient for drafts, but should be stated rather than left implicit. [Bug]: Thread interaction and runtime modes do not sync between desktop clients #5278 (thread modes not syncing between desktop clients) is a fair indicator of how much "this syncs correctly everywhere" actually costs.
• Offline regression. A client that can't reach the server currently keeps working on a local draft. Creating the thread up front means draft creation now requires the server, unless a local buffer is retained as a write-through cache.
• Deletion semantics. Deleting a draft is now a thread.delete, so it should be possible directly from the sidebar row without opening it, and shouldn't prompt with the same confirmation weight as deleting a thread with real history (confirmThreadDelete).
• Sidebar noise. Drafts occupy rows in a list otherwise about active work. Suppressing empty drafts and giving Draft a low-prominence treatment should contain this, but it deserves a look on projects with many threads.

Examples or references

• [Feature]: To-Do List & Queue/Steer Messages #4550 — To-Do List & Queue/Steer Messages (overlapping motivation, different surface)
• [Feature]: Scheduled Prompts #3624 — Scheduled Prompts (time-triggered variant of "run later")
• [Feature]: Queue follow-up messages while the agent is running #5507, feat: add Steer and Queue follow-up modes alongside Chat/Plan #231 — queued follow-ups while a turn is running
• [Bug]: Failed bootstrap leaves new-thread draft pinned to a deleted thread ID #4647 — tombstoned-draft-ID bug that this approach removes by construction
• [Bug]: Per-chunk assistant persistence causes progressive live output lag and rapid SQLite growth #5110 — per-chunk persistence causing lag and SQLite growth (prior art for the write-amplification risk)
• [Bug]: Thread interaction and runtime modes do not sync between desktop clients #5278 — thread modes not syncing between desktop clients (prior art for the sync cost)
• [Feature]: Prioritize Sidebar V2 threads that need review #4695 — Sidebar V2 review prioritization (would need to ignore draft threads)
• Relevant code, client: apps/web/src/composerDraftStore.ts (DraftId, getDraftThreadByProjectRef, markPromotedDraftThread), apps/web/src/components/Sidebar.logic.ts (resolveSidebarV2Status), apps/web/src/components/SidebarV2.tsx (the topStatus label block), apps/web/src/promptStashStore.ts
• Relevant code, server and contracts: packages/contracts/src/orchestration.ts (ThreadCreateCommand, ThreadTurnStartBootstrap), apps/server/src/orchestration/decider.ts (the side-effect-free thread.create branch), apps/server/src/ws.ts (bootstrap sequencing), apps/server/src/attachmentStore.ts (thread-keyed attachment ids)

Contribution

• I would be open to helping implement this.

[coygeek]

Additional use case: two-way sync for unsent drafts across connected clients

T3 Connect currently makes the environment and submitted thread state reachable from another authorized client, but an unsubmitted prompt remains in the originating client’s local composer storage. In practice, a prompt started on one macOS desktop is absent when the same connected environment is opened on a second desktop, even though both clients are connected. This makes the current sync one-way from the user’s perspective: work is shared after submission, while work still being composed is not.

The public source reflects this boundary: apps/web/src/composerDraftStore.ts persists composer drafts through a localStorage backed store. The observed clients were running T3 Code build 0.0.43-nightly.20260916.1825.

A focused acceptance boundary for the server-side draft persistence follow-on described in this discussion would be:

• A draft created on Client A appears on Client B after both clients connect to the same authorized environment, without copying or retyping the prompt.
• Editing the draft on either client propagates the updated text to the other while it remains unsent, with a deterministic rule for concurrent edits.
• Reloading either client retains a successfully synchronized draft.
• The draft never starts an agent turn or produces activity notifications merely because it exists.
• Submitting from either client starts exactly one normal first turn and leaves both clients showing the same resulting thread state.
• The behavior works through supported local, remote, and T3 Connect modes, with a clear recovery or status message when a draft cannot yet be synchronized.

This narrows the existing proposal to the two-way connected-client workflow and keeps the prompt unsubmitted until the user explicitly sends it.

[jonbrightdev]

Adding a mobile case to this proposal:

1. On desktop, start a new thread and type a prompt without sending it.
2. Switch focus to another thread. The draft remains visible as a row in the desktop sidebar.
3. Open the same connected environment/project in the T3 Code mobile app.

The draft thread is absent from the mobile thread list, so I cannot find or resume that unsent prompt on my phone. I expected the draft to appear on mobile and remain unsent until I explicitly submit it. The desktop screenshot shows the draft row after switching threads.

This seems to match the client-local draft storage described above. If maintainers are open to a focused PR for cross-device draft visibility/sync, I would be happy to help. What scope would you prefer?

[GammelSami]

Some weeks I have more ideas than my weekly usage allows, so I end up “ahead of pace” and have to ration my remaining usage for urgent tasks.
Other weeks I touch grass and spend less time using T3 Code and leave some of my paid usage unused!

I don’t want my ideas to languish somewhere else. I want to keep them where I’ll use them later: in the relevant T3 Code project.

My workaround to save a new thread draft for later:

1. select a cheap model
2. send the prompt
3. immediately stop the run

The downside:
Threads I’m saving for some week with spare usage clutter the sidebar.
I’ve started adding a “backlog” prefix to their titles to keep track of them:

I’d love a Backlog section below Snoozed. A place to put threads aside indefinitely.
Ideally, I could move new, unsent thread drafts there too. (or snooze them)