Allow devs to disable their application commands

[Soheab]

I’d like to suggest a built-in way for developers to disable specific application commands without deleting them. The current situation forces devs to soft delete, hide, or return errors. This isn’t a good UX and it becomes confusing for users.

Behaviour

• Add a per command toggle that marks the command as disabled. Then either

  • A: disabled commands do not appear in the client
  • B: disabled commands appear but are grayed out with a tooltip like “This command is disabled by the developer”

• Keep commands registered so re enabling is instant

• Applies to both global and guild commands

Use cases

• Turn off a command during maintenance
• Disable a command immediately incase of bugs
• Retire older commands without deleting them
• Keep commands visible for internal testers while making it clear to users that they’re inactive

Payload example

Here’s an example of how this could work using the existing Application Command object. This mirrors the current API layout and adds a proposed field called disabled.

{
  "name": "ping",
  "type": 1, // CHAT_INPUT
  "description": "Replies with pong",
  "disabled": true // New field
}

If disabled is set to true, the client can either hide the command or show it grayed out with a tooltip. There could even expose both options if desired.

This keeps the command registered, avoids the delete recreate cycle, and finally gives developers proper control over their own commands without relying on admins and the Integrations tab.

Related discussion

#4914 may be relevant, but not really the same thing.

This description was mostly written by ChatGPT. Apologies to anyone allergic to AI.

[Zoddo]

Related:

• Enabling/Disabling global commands per guild #4795

[Soheab]

I searched for any open discussion on the topic but couldn’t find any 😞

Well, that’s basically the same thing but with a different behaviour and reasoning.

[Zigmata]

A bit valid IMO considering that's an incredibly reasonable feature and the issue is 4y old.

[Soheab]

True, but I don't think opening multiple discussions about the same thing is going to speed up the process in any way.

Hope we bumped the other one somewhat with this.

[broman]

[Soheab]

Duplicate of #4795 (#7997 (comment))