[youknowriad]

Related issues

• Follow-up to Studio Code: Read the file a wp_cli --post_content path names #5305. Same case: STU-2155 header eval (Studio Code: Apply theme template edits to Site Editor customizations instead of silently missing them #5092, Studio Code: State the active site's WordPress version, block types, and Site Editor copies as facts #5301), where post update 5 --post_content=<site>/tmp/header-new.html saved the path as the header's content, and the agent reported success.
• Related to Studio Code: Check block content where it is saved instead of asking the agent to validate it #5241, which also finds the content file in post create/update commands so it can check that file's block markup.

How AI was used in this PR

Claude Code reviewed #5305 together with the other --post_content PRs (#5310, #5312, #5241), suggested this simpler fix, wrote the change and tests, and ran the checks below. I reviewed the diff.

Proposed Changes

#5305 handled this mistake by quietly rewriting the command so WP-CLI reads the file. This PR refuses the command instead, the same way wp_cli already handles $(cat file), typographic dashes and JSON that doesn't parse. When --post_content is just a file path, nothing is saved and the agent is told to pass the path as a positional argument (post update <id> <file>), which the tool description already recommends.

Why a refusal is better:

• It catches more cases. The rewrite only fired for an existing file inside the site folder. A missing file, a file outside the site, or a quoted path with a space still had the path saved as the content, which is the original bug. The refusal stops all of these.
• The agent learns the right call. The tool result shows the correct form, and nothing happens silently.
• It's a lot less code. No file-system access, no site path, and no extra line in the tool result: +28/−114.

Content that only mentions a path (See tmp/header.html, <p>tmp/header.html</p>), block markup and JSON are saved as before.

Testing Instructions

• npx vitest run apps/cli/lib/tests/wp-cli-post-content.test.ts apps/cli/ai: 332 pass. New cases: an absolute path, a relative path followed by --porcelain, a .json path (all refused); a bare word, text and markup that mention a path, and block markup (all saved as written).
• npm run typecheck passes.
• Eval: not run. The template-part-db-override case only hits this when the agent happens to make the mistake, so one run wouldn't show the difference.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

🤖 Generated with Claude Code

[wpmobilebot]

📊 Performance Test Results

Comparing 84210ae vs trunk

app-size

Metric	trunk	84210ae	Diff	Change
App Size (Mac)	940.75 MB	940.73 MB	0.02 MB	⚪ 0.0%

site-editor

Metric	trunk	84210ae	Diff	Change
load	1189 ms	1231 ms	+42 ms	⚪ 0.0%

site-startup

Metric	trunk	84210ae	Diff	Change
siteCreation	6486 ms	6489 ms	+3 ms	⚪ 0.0%
siteStartup	2872 ms	2881 ms	+9 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[chubes4]

This is how I originally had my PR written, but I decided to route the intent to reduce friction. Are you sure it's a problem?

[youknowriad]

Your rewrite isn’t wrong, and it saves a retry when the file exists in the site folder. I went with the refusal mainly for simplicity (I think going for the simplest solution compounds long term in a project). It also covers the cases the rewrite misses (missing file, file outside the site, path with a space), where the path still gets saved as the content. One retry seems a fair price for that, wdyt.

[chubes4]

I'm in full agreement about simpler = better. But sometimes we can compensate for the fact that LLMs are non-deterministic by allowing them to make mistakes and simply doing what they intended to do. I'm cool with either approach for this one