[Feature]: Add Claude Code /btw / Codex /side style ephemeral Side Chat on Orchestrator V2#15758

Problem

T3 Code has Steer and Queue for messages sent while an agent is working, but neither covers a different workflow:

Ask a quick question using the current thread's context without steering the active run and without adding the side exchange to the main thread's future context.

Claude Code now exposes this as /btw; Codex has the same general idea as /side.

This is especially useful in long-running agent sessions. While an agent is working, I may want to ask things like:

• Why did you choose this approach?
• What does this error mean?
• Is that dependency actually necessary?
• What are the tradeoffs of the thing you're currently doing?

Today the choices are all imperfect:

• Steer changes the active turn.
• Queue adds the question to the main conversation later.
• A new thread avoids pollution but loses the exact current conversational context.
• A normal fork is heavier than a disposable side question and becomes another thread to manage.

Desired behavior

Add a lightweight Side Chat / BTW action, available from the composer or command palette, with semantics roughly like:

1. Snapshot/inherit the parent thread's latest stable context.
2. Open a temporary side conversation.
3. Let me ask one or more questions there.
4. Do not add the side-chat messages or answers to the parent thread's subsequent context.
5. Do not interrupt, steer, or queue anything into the active parent run.
6. Closing the side chat simply discards/hides it.
7. Optionally allow Promote to thread or Merge back when I explicitly decide the detour is useful.

If the parent is currently running, using the latest stable forkable boundary is fine. The important property is context-aware isolation, not necessarily access to partially streamed tokens.

A slash command such as /btw / /side would be nice, but a first-class UI action is equally good.

Why this is worth revisiting after Orchestrator V2

This was already explored before V2:

• #9274 requested a side question using current context without polluting the main thread. It was closed during the feature-proposal cleanup and redirected to Ideas.
• Discussion #7311 is the canonical Codex-style /side / SideChat request.
• #12793 proposed temporary SideChat tabs and was closed as a duplicate of #7311.
• PR #9436 implemented the server/provider side of forks + side chats.
• PR #9437 implemented the web/mobile SideChat UX.

The maintainer closure on #9436/#9437 explicitly said the orchestration/provider layers were being rewritten for V2 and invited a fresh PR/request once V2 landed.

V2 has now landed via #2829, and current main already has much of the foundation that the old SideChat implementation had to build itself:

• thread.fork
• ThreadForkService
• thread lineage
• context transfer
• provider-aware native/portable forking
• thread.merge_back
• web/mobile fork navigation
• MCP t3_thread_fork

There is even current user-facing fork/merge-back behavior, e.g. #15063.

So this request is intentionally not asking to revive the old orchestration implementation. It is asking whether the new V2 fork/context-transfer primitives can now be surfaced as a lightweight ephemeral SideChat workflow.

Relationship to Steer / Queue

This is intentionally a third semantic:

That distinction is the feature.

Possible minimal V1

A small first version could be:

• "Open side chat" action on the thread/composer
• fork from the latest stable run using existing V2 machinery
• side chat shown in the right panel on web/desktop
• hidden from the normal thread list while attached to its parent
• close/discard
• promote to normal thread

Merge-back, multiple side tabs, mobile polish, and provider-specific shortcuts could come later.

The old #9437 UX is useful prior art, but the implementation should target the current V2 architecture.