[BUG] /doctor unavailable in desktop GUI; report commands differ across surfaces

Summary

Claude Code's support-guided report/diagnostic commands are inconsistent across surfaces, and /doctor is unavailable in the Claude desktop GUI.

This matters because support guidance for Claude Code false-positive safety/guardrail reports points users to /feedback, /bug, and /doctor. When those commands are unavailable or behave differently depending on surface, users do not have a reliable private reporting path.

Related context: https://github.com/anthropics/claude-code/issues/64287

Observed behavior

• In an affected native/CLI Claude Code session, /feedback returned unavailable.
• In the same affected native/CLI context, /bug also returned:

"/bug isn't available in this environment."

• In the Claude desktop GUI, /feedback opened the Submit feedback / bug report modal.
• In the Claude desktop GUI, /bug opened the same Submit feedback / bug report modal.
• In the Claude desktop GUI, /doctor returned:

"/doctor isn't available in this environment."

• The Claude desktop GUI also showed this warning banner at the same time:

We are experiencing technical difficulties. Some functionality may be temporarily unavailable.

Expected behavior

• Support-documented reporting commands should behave consistently across Claude Code surfaces, or clearly explain which surface/environment supports each command.
• /doctor should either run where support guidance tells users to run it, or the UI should route users to the correct equivalent diagnostic path.
• If /feedback and /bug are product-reporting routes, they should provide a reliable private path for false-positive safety/guardrail reports without depending on the user discovering which Claude Code surface currently supports them.

Impact

When a user hits false-positive safety/guardrail blocks, support routes them toward product-native commands. If those commands return unavailable or are inconsistent, the report gets pushed into external support / User Safety / GitHub loops instead of a direct request-ID-keyed product review path.

This report is intentionally sanitized: no private request IDs, support conversation IDs, org IDs, local paths, logs, or account details are included.