Plugin/marketplace ops fail silently and indefinitely if known_marketplaces.json has a UTF-8 BOM

Preflight

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

A UTF-8 BOM (EF BB BF) at the start of ~/.claude/plugins/known_marketplaces.json makes every claude plugin marketplace / /plugin operation fail. The JSON parser rejects the BOM.

The more serious half is not the BOM — it's that the failure is silent and unbounded. Nothing validates this file at startup. Claude Code launched and ran normally for 9 days (2026-07-28 → 2026-08-06) with all plugin and marketplace functionality broken, and surfaced no warning at any point. It only became visible when a plugin install was attempted and the command errored.

On Windows this is easy to hit accidentally: PowerShell's Out-File, Set-Content, and > all default to UTF-8 with BOM. Any tool, script, or hook that rewrites a .claude JSON config through PowerShell reintroduces it. The same exposure applies to installed_plugins.json and settings.json.

What Should Happen?

Either of these would have prevented 9 days of silent breakage; ideally both:

1. Accept the BOM on read. Parse these configs as utf-8-sig rather than strict utf-8. A BOM is legal UTF-8 and is what Windows tooling emits by default. This is a one-line tolerance change and makes the whole class of failure disappear.
2. Fail loudly at startup. If a core config under ~/.claude/ is unparseable, say so on launch rather than deferring the error until the first operation that happens to need it. A config the product cannot read is worth one line of startup output.

Anything that writes these configs should also write BOM-free explicitly, rather than inheriting the platform default.

Error Messages/Logs

Failed to load marketplace configuration: JSON Parse error: Unrecognized token ''

Steps to Reproduce

1. On Windows, add a UTF-8 BOM to ~/.claude/plugins/known_marketplaces.json — e.g. rewrite it through PowerShell's default encoding (Get-Content f.json | Out-File f.json), or prepend the bytes EF BB BF directly.
2. Start Claude Code. Observe: no warning, no error, startup looks completely normal.
3. Run any plugin or marketplace operation:

``
claude plugin marketplace add <owner>/<repo>
``

1. Observe the parse error above. /plugin fails the same way.

Detect: head -c3 ~/.claude/plugins/known_marketplaces.json | od -c — 357 273 277 means BOM.
Fix: rewrite without one (read encoding='utf-8-sig', write encoding='utf-8').

Is this a regression?

Unsure — not certain when this behaviour was introduced.

Additional context

I can't determine what wrote the BOM in my case. A sibling backup (known_marketplaces.json.bak-doctor-20260728, BOM-free) suggests a repair or migration path ran on the day the breakage started, but the original bad file was overwritten when I fixed it, so that's circumstantial and I'd rather not point at a specific code path without evidence.

The origin matters less than the two properties above: the parser is stricter than the platform's default encoding, and a broken core config produces no signal until something trips over it.