Slash commands unavailable until the first message is sent

[LordLox]

Problem / Motivation

When a new chat session opens, the slash-command menu is empty: typing / shows nothing and the command button is unavailable. The commands only appear after the user has sent at least one ordinary message. That is backwards for the most common reason people reach for a command in the first place — starting a session with /resume, /model, /init or a project skill — and it makes the feature look broken on first contact, since nothing on screen explains that a message has to be sent first.

Goal

The command menu is populated and usable as soon as a session is ready, without the user having to send a throwaway message to unlock it — for every agent integration that supports commands.

Scope

• Commands are available in a freshly opened session, before any message has been sent.
• The same holds for a session reopened from history and for a session started in a new tab.
• Audit every supported agent integration, not just the default one: for each, either commands are available at session start, or the fact that the integration offers no commands is presented honestly instead of looking like a menu that failed to load.
• When an integration genuinely cannot report its commands until later, the interface should not present an empty, silent menu — it should make clear that the list is still loading or unavailable.

Non-goals

• Adding, renaming, or changing what any command does.
• Inventing a command list for an integration that does not actually support commands.
• Changes to the file-mention picker or attachments, beyond keeping their behaviour unchanged.

Acceptance Criteria

• In a brand-new session with no messages sent, typing / opens the command menu with the expected entries.
• The command button in the composer is usable in a brand-new session.
• Selecting a command as the very first action of a session runs it correctly.
• Reopening an existing session from history shows the command menu immediately, without sending a message.
• Each supported agent integration has been checked and its behaviour documented in this issue or its follow-up: commands available at start, or explicitly none.
• No integration shows a permanently empty command menu with no explanation.

Open Questions

• For an integration that offers no commands at all, should the command button be hidden entirely or shown disabled with a short explanation?

[dnviti]

Fixed in #41. Per-integration audit, as requested in the acceptance criteria:

• claude — was the actual bug: the CLI only reports slash_commands on the first turn's system/init, which it doesn't emit until it has received a message on stdin, even though this app spawns the process as soon as the chat is opened. Fixed by advertising a static baseline of this app's own built-in command table from the moment the adapter starts; the runtime's own list (including project/plugin commands) still arrives with the first turn and replaces the baseline outright.
• kimi, omp (ACP) — already fine. Both report their command list via an available_commands_update notification during the handshake, before any message is sent.
• codex, grok, pi — no command support at all today. The composer already hides the command button entirely rather than showing an empty menu, which is the honest behavior for a runtime that offers none. Not a regression from this issue, and adding command support to these is out of scope here.

All four acceptance criteria involving the menu/button at session start are covered for claude, the only runtime that was actually broken.

[dnviti]

Landed in #41, on the 5.1.2 release branch.

The runtime's slash commands are now available from the moment a conversation opens, via a baseline list the adapter declares up front, rather than only after the agent had spoken for the first time. The list is still replaced by whatever the runtime actually reports once it initialises — including after a /clear restart, which re-seeds it through the new process's own init.