Confirmed — /new is unhandled in both TUI surfaces, so it falls through to "unknown command":

librefang tui chat tab → tui/mod.rs::handle_slash_command has arms only for /exit /quit /help /status /agents /clear /kill /model /hands; no /new, so it hits the _ => default.
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 is registered Scope::CHANNEL-only (librefang-channels/src/commands/mod.rs), so it fails the gate.

The dashboard (ws.rs → create_agent_session) and channels (bridge.rs, #4868) both handle /new correctly — this is TUI-specific.

One semantic decision before the fix: the dashboard/command-catalog define /new as "start a new session" (a fresh session id), while the channels registry describes it as "reset session (clear messages)" — different operations (there's a separate /reset for clearing). I'll align the TUI with the dashboard's "create a new session" semantics unless you'd prefer reset.

Fix is small: widen /new to Scope::CHANNEL | Scope::CLI, add a /new arm to both TUI handlers (the create-session plumbing already exists in the kernel/HTTP layer), and add the i18n key. Will open a PR.

Uh oh!

Uh oh!

/new command does not work #6265

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions