[BUG] /config outputStyle picker lists only the 4 built-in styles — a custom style from ~/.claude/output-styles is active but never selectable (2.1.226)

Preflight Checklist

• [x] I have searched existing issues and this has not been reported yet. The closest match is #75351 (closed as duplicate), which reports the inverse case: a plugin style that appears in the picker but never applies. See the regression note below.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.226)

What's Wrong?

A custom output style in ~/.claude/output-styles/ loads and applies correctly, but the /config picker never lists it. The picker offers only the four built-in entries.

Type /config outputStyle= and the completion shows exactly this:

outputStyle=default
outputStyle=Proactive
outputStyle=Explanatory
outputStyle=Learning

My style is active at that moment. The value column of the Output style row shows ASD-STE100, and the status line reports the same name from the output_style.name field of the status-line payload. So discovery works and activation works. Only the list of choices is wrong.

Cause. The 2.1.226 bundle holds the styles in two separate places, and the picker reads the built-in one. The row definition is:

{id:"outputStyle",label:"Output style",
 value: Ip("outputStyles") && !Object.hasOwn($ye,o) ? `${o} (disabled in safe mode)` : o,
 type:"managedEnum",
 options: Object.keys($ye),
 optionsHint:"For custom styles, open /config.", ...}

$ye is the static map of built-in styles. It holds [cj]:null where cj="default", plus name:"Proactive", name:"Explanatory" and name:"Learning", each with source:"built-in". That is the four rows above.

The merged map that resolves the active style comes from a different, asynchronous function:

if(Ip("outputStyles")) return {...$ye};
let r = await oQp(t), n = await lFs(), o = {...$ye},
    i = r.filter(c=>c.source==="policySettings"),
    s = r.filter(c=>c.source==="userSettings"),
    a = r.filter(c=>c.source==="projectSettings"),
    l = [n,s,a,i];
for (let c of l) for (let u of c) o[u.name] = {...};
return o

This function merges the plugin styles, the user directory, the project directory and the policy settings. The picker row never uses its result, so a style that comes from a file can never appear in the list, whatever its name or frontmatter.

A second sign that this is an oversight. The hint on the row reads "For custom styles, open /config.", and the row itself sits in /config. That text was written for the separate /output-style command, which this version removed. The bundle carries the removal notice: Output styles are configured via \/config\, not \/output-style\. and Output styles still exist as a feature; only the dedicated command was removed. The command went away, its picker moved into /config, and the option list kept the built-in constant.

Why this hurts more than a cosmetic gap. The onChange of the row writes to the local project scope:

let B = await ts("localSettings",{outputStyle:j});

So one pick inside a repository writes outputStyle to that project's local settings, and that value then overrides the global custom style in that repository. The user cannot pick the custom style back, because the name is absent from the list. The only exit is a manual edit of the JSON. A user who does not know the internals reads the short list as proof that the custom style is broken or gone.

Safe mode is not involved. Both restriction maps set outputStyles:!1.

What Should Happen?

The picker lists every style that the resolver can return: the built-in styles, the styles in ~/.claude/output-styles/, the styles in the project directory, plugin styles and policy styles. The active style must always be one of the choices, so a user can switch away and switch back.

Error Messages/Logs

There is no error and no warning. The failure is silent. The evidence is the set of strings in the bundle quoted above.

Steps to Reproduce

1. Write ~/.claude/output-styles/my-style.md with valid frontmatter: name: My-Style, a description, and keep-coding-instructions: true.
2. Put "outputStyle": "My-Style" in ~/.claude/settings.json.
3. Start a session. The style applies. A status line that prints output_style.name shows My-Style.
4. Type /config outputStyle= and read the completion. Only default, Proactive, Explanatory and Learning appear. My-Style is absent.
5. Open /config and look at the Output style row. The value reads My-Style, but the list of choices does not hold it.
6. Pick default from the list. The pick lands in the project local settings. Now no path through the UI returns you to My-Style.

Claude Model

Opus 5 (1M context). The model does not matter for this bug.

Is this a regression?

Yes, this worked in a previous version.

I did not test an old build myself, so I mark this with care. Issue #75351 reports a plugin-provided output style that appeared in the /config picker on 2.1.202, three weeks before the /output-style command was removed. That report is evidence that the list once held styles from outside the built-in map. Issue #64914 (closed as stale) reported a discovery failure and is a different problem.

Last Working Version

2.1.202, per the evidence in #75351. I have not confirmed this against a local install of that build.

Claude Code Version

2.1.226 (Claude Code), native install

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

A workaround for anyone who lands here: the active style is still visible in two places. The value column of the Output style row in /config shows the real name, and the status-line payload holds output_style: { name }, so a status-line script can print it permanently. To change styles, edit outputStyle in the settings JSON by hand, and treat the picker list as read-only.

Two small fixes look sufficient, and they are independent:

1. Feed the picker from the merged resolver instead of Object.keys($ye).
2. Remove or rewrite the optionsHint, which now points at the panel that shows it.