mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-16 06:50:34 +00:00
724e90c3c8
* feat(ui): redesign /btw side chat into floating multi-turn panel The inline BTW side-result card becomes a floating Side chat panel pinned to the thread column: multi-turn conversation with markdown answers, a follow-up input that carries the previous side answer as context, and header actions to clear (retires the pending run) or close (conversation and pending run survive; an arriving answer reopens the panel). * fix(ui): carry prior side question in follow-ups; display typed question structurally Review follow-ups: the /btw follow-up command now embeds both the previous side question and answer (answers alone lose the referents), and the panel shows the user's typed question via structured state (pending record correlated by runId) instead of parsing a marker out of user-controlled command text. * fix(ui): stop pending side runs on clear and keep rejected follow-up drafts Trash now sends a targeted chat.abort for the pending /btw run (the retire set still suppresses its late events if the abort races), the follow-up input is hidden while disconnected like other slash sends, and a rejected detached send restores the typed follow-up into the panel input. * test(ui): attach side-chat panel test container for restore assertion * fix(ui): block side-chat follow-ups while pending; notify rejection on pre-send exits A follow-up while a question is pending would retire the in-flight run and silently drop its answer, so the panel input is disabled until the answer lands. The rejection callback now fires on every non-accepted path of the guarded detached send (early exits, guard dedupe, rejected acks), not just rejected acknowledgements. * fix(ui): render side-chat questions verbatim Pending and turn questions are already display-ready (chat-send strips composer commands, the server echo carries no /btw prefix, panel follow-ups pass structured text); re-extracting corrupted questions that begin with a command token.
110 lines
5.4 KiB
Markdown
110 lines
5.4 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.
|
|
|
|
```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,
|
|
persist question/answer data to transcript history, or survive a reload.
|
|
|
|
## Delivery model
|
|
|
|
Normal assistant chat uses the Gateway `chat` event. BTW uses a separate
|
|
`chat.side_result` event so clients cannot mistake it for regular
|
|
conversation history. Because it is not replayed from `chat.history`, it
|
|
disappears after reload.
|
|
|
|
## 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 | Rendered as a floating "Side chat" panel pinned to the thread. Answers accumulate as turns and a "Follow up" input asks the next side question. Close (`Esc` or the X) keeps the conversation and reopens on the next answer; the trash button discards it and stops a pending run. |
|
|
|
|
## 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 sends an implicit `/btw` question asking the
|
|
model to explain the highlighted text in the context of the current
|
|
session. The answer arrives in the floating side chat panel.
|
|
- **Ask in side chat** pre-fills the composer with a `/btw` draft quoting the
|
|
highlighted text so you can type your own question about it.
|
|
|
|
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>
|