[BUG] Output content filter blocks legitimate code-signing build scripts (false positive on Authenticode / Microsoft Store signing)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

ENVIRONMENT

• Tool: Claude Code (CLI)
• Model: Claude Opus 4.8 (1M context), model id claude-opus-4-8
• OS: Windows 10
• Task context: building a real, authorized Microsoft Store / direct-distribution desktop app

(Avalonia / .NET). Part of the build pipeline is two standard Windows batch scripts:

1. create a self-signed CODE-SIGNING certificate (PowerShell New-SelfSignedCertificate,

type CodeSigningCert), export a password-protected .pfx + public .cer;

1. Authenticode-sign the produced .exe with the Windows SDK signtool (SHA-256 digest,

RFC-3161 timestamp) and verify it.
This is an extremely common, entirely legitimate developer task.

SUMMARY
When asked to GENERATE the content of these two code-signing scripts, the model output is blocked by the
API content-filtering policy. The request fails with:

API Error: 400 "Output blocked by content filtering policy"

with zero output tokens produced. The block is on the model's OUTPUT generation (not the input/prompt).

REPRODUCTION

1. In a normal software project, ask Claude Code (or dispatch a sub-agent) to write two Windows .bat

scripts: one that creates a self-signed code-signing certificate and exports a .pfx, and one that signs
an executable with signtool and a timestamp server. Frame it plainly as signing your own app for the
Microsoft Store / direct download.

1. The model performs its research/read steps normally, then attempts to emit the script content.
2. At the moment it generates the certificate-creation + executable-signing content, the turn fails with

the 400 "Output blocked by content filtering policy" error and produces nothing.

REPRODUCIBILITY
100% reproducible in this session. It occurred on two independent sub-agent dispatches (each died at the
same point, ~30 tool calls in, with 0 output tokens and nothing written to disk). It is content-triggered,
not transient: re-running reproduces it. The same block applies to the main assistant generating the same
content, so it is not specific to sub-agents.

IMPACT

• A standard, legitimate, authorized developer workflow (code-signing your own application, MSIX / Store

packaging, Authenticode) cannot be completed by the model at all.

• The only workaround was to generate the two scripts with a DIFFERENT AI (Google Gemini) and paste them

into the project manually. Every other artifact in the same task (build scripts that do NOT involve
signing, deployment docs, manifests, license notices) generated without any problem - so the trigger is
specifically the code-signing-certificate + executable-signing script content.

EXPECTED BEHAVIOR
Generating ordinary code-signing scripts (New-SelfSignedCertificate with the CodeSigningCert type, and
signtool sign/verify) for one's own application should not be blocked. The classifier appears to
false-positive on standard Windows code-signing tooling, presumably because "create a certificate and use
it to sign an executable" superficially resembles malware-signing patterns. The filter cannot distinguish
legitimate first-party app signing (the overwhelmingly common case) from abuse, and currently blocks the
legitimate case outright.

SUGGESTED REMEDIATION

• Tune the output classifier so that standard, self-contained code-signing scripts (self-signed dev cert

creation + Authenticode signing of a locally-built binary, with timestamping) are not treated as
disallowed content.

• At minimum, the failure mode is poor: a hard 400 that discards the entire turn with zero output and no

actionable message. If content must be withheld, a graceful, explainable refusal (rather than a 400 that
kills a sub-agent mid-task and writes nothing) would let the workflow recover.

ADDITIONAL NOTES

• No malicious or evasive intent was present or requested; the scripts are standard, well-documented

Windows SDK / PowerShell usage that appears in countless public tutorials and Microsoft's own docs.

• The blocked content was eventually produced by another vendor's model without issue, indicating the

threshold here is notably more aggressive for this category.

What Should Happen?

Claude should write code

Error Messages/Logs

Steps to Reproduce

See above

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.165

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_