[Feature]: Auto-discover provider slash commands

[keyzou]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

I've seen some confusion in #1283 after the related PR was merged, which is valid from a UX standpoint: ideally, when I write /, I should see the slash commands my Codex / Claude Code has access to.
However, that's not the case today. The point of that issue and PR was to give the SDK access to the user / project configurations, thus allowing Claude Code to internally discover those resources so it can reuse them, which is unrelated to T3 Code's UI.

Which is why I'm making a proper feature request here !

The point of the feature would be to allow T3 Code to discover those commands automatically.

However, things are not that simple today:

• The command selector currently only handles hardcoded commands (/model, /plan /default)
• Claude's SDK provides a slash_commands in its session/init event, but Codex doesn't provide any easy way to get this information (from what I've read in their documentation)
• Which also means that, in Claude's case, since we can't naturally get the information out before engaging a session, the first message of a thread cannot have the suggestions.
• Also, they only provide the skill names, so we don't have access to descriptions / metadata

Proposed solution

Discovery:

• At a given frequency, scan the different configuration scopes: project, user, local, managed for slash commands (usually tied to skills) and extract:
  • Command name
  • Description (if applicable)
  • Scope
• Possible frequencies:
  • When starting the server
  • When creating a thread
  • When opening the command menu (typing /)
• Build an array of slashCommands that will contain:
  • name: name of the command
  • description (optional): small description if the command has one
  • scope: Which configuration it comes from. If none, it is certainly a built-in
• Depending on how frequently we fetch it, many options for storage (in memory, sqlite, etc...)

After the discovery part is solved, the rest is fairly straightforward:

• Allow the command menu to be more extensible to receive commands from different "providers" (I believe the three commands are hardcoded today?)
• Pass the discovery results down to the picker (store the information in the thread ?)
• Show it to the user depending on which model is selected (so that we show Claude commands only when a Claude model is selected, same for Codex)

Unlike T3 Code's special commands (/model, /plan, /default), no hooks should be needed to catch the commands: this is handled by the provider's CLI (at least it is for Claude Code, not sure about Codex)

Why this matters

People don't want to know all their slash commands by heart, it's just good UX to give them a list of what they can do :)

Smallest useful scope

Claude only: Would be very clunky, but we could grab the information from the session/init event so that we don't bother with the filesystem, which would only leave us with the command, no description or scope.

For something universal, the "MVP" must include the filesystem search to cover Codex, but could just rely on search results, unlike the proposed solution that would require some kind of parsing to extract the description

Alternatives considered

There are a few mitigations possible for the discovery part, but somewhat clunky:

• Rely on the session/init event from Claude SDK
  • => Codex has no equivalent
  • => Claude only provides the name of the skill, nothing else
  • => Can only be done after engaging a session
• Make it a setting where the user can specify their skills and commands
  • => Defeats a bit of the purpose given that they could just write the slash command directly in their prompt and Claude Code would recognize it, this would not be great UX anyway
• A small, invisible session to parse the session/init event or Claude
  • => Claude only, and using tokens behind the user's back is a no-go :)

Not much alternatives for the other aspects I believe ?

Risks or tradeoffs

Not everything here will end up being an actual risk, just getting everything out of my head

• Overhead of having to search the filesystem and parse files
• We might someday parse a malicious file
• We might miss some skills if we're not thorough (in monorepos for example)
• User has some skills that aren't in the places we check (legacy places like .claude/commands/) ?

Examples or references

Example UI (didn't grab the description here):

(I have a working proof of concept but was waiting to validate the direction with the maintainers to create a PR)

Contribution

• I would be open to helping implement this.