mirror of
https://github.com/openclaw/openclaw.git
synced 2026-08-03 18:21:37 +00:00
* refactor(gateway): remove dead sessions.observer.ask rpc * docs: record btw and companion contract split * fix(gateway): unexport observer model sanitizer after ask removal
114 lines
5.7 KiB
Markdown
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>
|