Files
openclaw/docs/tools/btw.md
Peter Steinberger ce5ab8adb8 refactor(gateway): remove dead sessions.observer.ask rpc (#113791)
* refactor(gateway): remove dead sessions.observer.ask rpc

* docs: record btw and companion contract split

* fix(gateway): unexport observer model sanitizer after ask removal
2026-07-25 14:44:02 -07:00

114 lines
5.7 KiB
Markdown

---
summary: "Ephemeral side questions with /btw"
read_when:
- You want to ask a quick side question about the current session
- You are implementing or debugging BTW behavior across clients
title: "BTW side questions"
---
`/btw` (alias `/side`) asks a quick side question about the **current
session** without adding it to conversation history. It is modeled after
Claude Code's `/btw`, adapted to OpenClaw's Gateway and multi-channel
architecture.
The two side-question contracts are deliberately separate. BTW is a one-shot question on the session's actual model, preserving harness behavior and Codex thread-fork continuity for channel ingress (WhatsApp, Telegram, and Discord), the TUI, and embedded `tui --local`; the TUI stays on BTW by design. The companion is a persistent, read-only RPC thread for Control UI-class clients. Channels cannot use the companion because they do not have an RPC connection.
```text
/btw what changed?
/side what does this error mean?
```
## What it does
1. Snapshots the current session as background context (including any
in-flight main-run prompt).
2. Runs a separate, one-shot side query telling the model to answer only the
side question and not resume or steer the main task.
3. Delivers the answer as a live side result, not a normal assistant message.
4. Never writes the question or answer to session history or `chat.history`.
The main run, if one is active, is left untouched.
For Codex harness sessions, BTW forks the active Codex app-server thread into
an ephemeral child thread instead of running a separate provider call. This
keeps Codex OAuth and native tool/thread behavior intact, and the forked
thread keeps the parent thread's current approval policy, sandbox, and native
tool surface. The forked thread gets a boundary prompt telling the model that
everything before it is inherited reference context, not active instructions,
and that only messages after the boundary are live. `/btw` requires an
existing Codex thread; send a normal message first.
For CLI runtime aliases, BTW invokes the owning CLI backend in one-shot
side-question mode: it seeds sanitized conversation context into a fresh CLI
invocation with tool bundling and reusable session state disabled, and adds
any no-resume/no-tools flags the backend supports. Direct (non-CLI) runtimes
use a direct one-shot provider call instead.
## What it does not do
`/btw` does not create a durable session, continue the unfinished main task,
or persist question/answer data to transcript history. Detached BTW results do
not survive a reload. The Control UI companion can rehydrate its in-memory
thread after a reload, but the thread is cleared by a session reset, Gateway
restart, idle expiry, or the rail's clear button.
## Delivery model
Normal assistant chat uses the Gateway `chat` event. Detached BTW uses a
separate `chat.side_result` event so clients cannot mistake it for regular
conversation history. The Control UI does not consume that event; it calls the
session companion RPCs and renders their bounded exchange state in the rail.
## Surface behavior
| Surface | Behavior |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TUI | Rendered inline in the chat log, visibly distinct from a normal reply, dismissible with `Enter` or `Esc`. |
| External channels | Delivered as a clearly labeled one-off reply (Telegram, WhatsApp, Discord have no local ephemeral overlay). |
| Control UI / web | Routes `/btw` and `/side` to the expanded session rail companion. The read-only thread is keyed by session, rehydrates from Gateway memory, and can be cleared with the trash button. `Esc` collapses the rail. |
## Selection popup (Control UI)
Highlighting text inside a chat message in the Control UI opens a small
selection popup with two actions:
- **More details** immediately asks the session rail companion to explain the
highlighted text in the context of the current session.
- **Ask in side chat** opens the rail and pre-fills its composer with a quoted
draft so you can type your own question about the selection.
Both actions follow normal `/btw` semantics: the question and answer stay out
of session history and the main run is left untouched.
## When to use it
Use `/btw` for a quick clarification, a factual side answer while a long run
is still in progress, or a temporary answer that should not enter future
session context.
```text
/btw what file are we editing?
/btw summarize the current task in one sentence
/btw what is 17 * 19?
```
For anything you want to become part of the session's future working
context, ask normally in the main session instead.
## Related
<CardGroup cols={2}>
<Card title="Slash commands" href="/tools/slash-commands" icon="terminal">
Native command catalog and chat directives.
</Card>
<Card title="Thinking levels" href="/tools/thinking" icon="brain">
Reasoning effort levels for the side-question model call.
</Card>
<Card title="Session" href="/concepts/session" icon="comments">
Session keys, history, and persistence semantics.
</Card>
<Card title="Steer command" href="/tools/steer" icon="arrow-right">
Inject a steering message into the active run without ending it.
</Card>
</CardGroup>