Skip to content

fix(cli): handle /new in the TUI chat surfaces (closes #6265)#6284

Merged
houko merged 3 commits into
mainfrom
fix/tui-new-command
Jun 23, 2026
Merged

fix(cli): handle /new in the TUI chat surfaces (closes #6265)#6284
houko merged 3 commits into
mainfrom
fix/tui-new-command

Conversation

@houko

@houko houko commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Problem

Closes #6265. /new printed "unknown command" in both terminal-UI chat surfaces:

  • librefang tui chat tab (tui/mod.rs::handle_slash_command) had no /new arm.
  • librefang chat (tui/chat_runner.rs::handle_slash_command) gates every command on the central registry returning a def whose scope contains Scope::CLI, but /new was registered Scope::CHANNEL-only.

The dashboard (ws.rscreate_agent_session) and channels (bridge.rs, #4868) already handle /new; only the TUI was broken.

Fix

/new now resets the agent's backend session and clears the local transcript.

Why reset, not create

My triage comment floated aligning with the dashboard's create-new-session semantics. On implementation I went with reset instead, for two concrete reasons:

  1. The TUI conversation talks to the agent by agent_id and never tracks an explicit session id, so create_agent_session would mint a session the TUI does not switch to — an orphan. reset_session(ResetScope::Agent) actually affects the conversation the user is in (a real "start fresh").
  2. The shared command registry already documents /new as "Reset session (clear messages)" and channels implement exactly that (Channel /new wipes ALL agent sessions, not just the channel-derived one #4868). Reset keeps the CLI surface consistent with the registry contract it consults, and is distinct from /clear, which only wipes the on-screen transcript without touching the backend session.

The pre-existing dashboard divergence (its /new creates) is out of scope here; unifying all three surfaces is a separate decision (noted on the issue).

Changes

  • librefang-channels/src/commands/mod.rs — widen /new scope to Scope::CHANNEL | Scope::CLI so the chat_runner gate admits it; description unchanged (already fits both). Adds a registry regression test.
  • tui/chat_runner.rs + tui/mod.rs/new arms: daemon backends POST /api/agents/{id}/session/reset; in-process backends call kernel.reset_session(.., ResetScope::Agent) on a scoped runtime (the TUI main thread is not on a tokio runtime, so block_on is safe). Both clear the local view + confirm. tui/mod.rs also gains a /help line.
  • locales/{en,uk,zh-CN}/main.ftl — the five new strings, parity-complete.

Verification

  • cargo check -p librefang-cli -p librefang-channels — clean (Docker dev image).
  • cargo test -p librefang-channels --lib commands::tests::new_command_is_reachable_from_cli_and_channel — pass.
  • cargo test -p librefang-cli --test i18n_checks — 3/3 pass (no_dead_locale_keys, locales_cover_used_i18n_keys, no_untranslated_strings), so locale parity holds.

`/new` was unhandled in both terminal-UI slash dispatchers, so it fell through to "unknown command":

- `librefang tui` chat tab (`tui/mod.rs::handle_slash_command`) had no `/new` arm.
- `librefang chat` (`tui/chat_runner.rs::handle_slash_command`) gates every command on the central registry returning a def whose scope contains `Scope::CLI`, but `/new` was registered `Scope::CHANNEL`-only.

The dashboard and channel surfaces already handle `/new`; only the TUI was broken.

`/new` now resets the agent's backend session and clears the local transcript — matching the shared command registry's contract ("Reset session (clear messages)") and the channel behavior (#4868), and distinct from `/clear`, which only wipes the on-screen transcript. The registry scope is widened to `Scope::CHANNEL | Scope::CLI` so the chat_runner gate admits it; the existing description fits both surfaces unchanged. Daemon backends POST to `/api/agents/{id}/session/reset`; in-process backends call `kernel.reset_session(.., ResetScope::Agent)` on a scoped runtime (the TUI main thread is not itself on a tokio runtime, so a `block_on` is safe). Adds the en/uk/zh-CN strings and a registry regression test.
@github-actions github-actions Bot added size/M 50-249 lines changed area/channels Messaging channel adapters labels Jun 23, 2026
claude and others added 2 commits June 23, 2026 03:48
CI's rustfmt wraps the long assert!-with-message form while the local toolchain keeps it on one line; short message-less asserts are formatted identically by every version, so the fmt lane stops flapping. The doc comment carries the #6265 rationale.
@houko
houko merged commit 480d78e into main Jun 23, 2026
31 checks passed
@houko
houko deleted the fix/tui-new-command branch June 23, 2026 04:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/channels Messaging channel adapters size/M 50-249 lines changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

/new command does not work

2 participants