[chubes4]

Related issues

• Follows Studio Code: Read the file a wp_cli --post_content path names #5305, which stopped wp_cli post create|update --post_content=<file> from saving the file's path. This PR handles another way a post gets saved wrong while the command still reports success.

How AI was used

Claude (via the Pi coding agent in a Roadie session) found the failure in eval transcripts, wrote the change and tests, and ran the eval below. I reviewed the diff and the results.

Proposed Changes

When wp_cli post create|update --post_content=… content starts with { but doesn't parse as JSON, the tool saves nothing and returns the parse error:

Nothing was saved: `--post_content` starts with `{` but is not valid JSON (Expected ',' or '}' after property value in JSON at position 174 (line 1 column 175)). WordPress ignores JSON post content that does not parse.

Block markup and HTML never start with {, so content that does is JSON, such as a Global Styles post. When WordPress can't parse a Global Styles post, it ignores the whole post. WP-CLI still saves it and prints Success: Updated post 5., so the agent has no sign anything went wrong.

That happened in an eval run of global-styles-db-override. The agent's JSON was missing its last }. Over the next 45 tool calls it checked the CSS, cleared transients, read the theme JSON resolver's source, and hex-dumped the post before finding the syntax error. The run used 1.4M tokens; the other runs used about 90k.

The check is in getUnsupportedWpCliPostContentMessage, next to the existing $(cat …) refusal. It doesn't depend on post types or the database. It refuses instead of repairing because there's no single correct fix for broken JSON.

Testing Instructions

• npx vitest run apps/cli/lib/tests/wp-cli-post-content.test.ts covers the exact command from the failed run. It is refused with the parse error, and the same command with the brace restored is accepted.

• Replay on a real site: the failed run's command, sent unchanged through wp_cli, was refused with the message above. The Global Styles post kept its previous valid content (#f6efe4, line height 1.7).

• Eval: global-styles-db-override, 6 runs on this branch. All 6 passed.

  Run	Result	Tokens	Calls	What happened
  0	Pass	209k	16	Refused once, then saved valid JSON on the next call
  1	Pass	110k	10
  2	Pass	209k	14	Refused once, then saved valid JSON on the next call
  3	Pass	203k	15
  4	Pass	1029k	42	Saved with wp in Bash, which this check doesn't cover. Its JSON was missing the last }, and it took the same debugging spiral
  5	Pass	200k	13

  In both refused runs, the agent's JSON was valid but wp_cli split the quoting wrong. Run 0 wrapped the whole argument in single quotes, so a trailing ' ended up in the content. Run 2 escaped the inner double quotes with backslashes, so the content was cut to {\. On trunk, both would have been saved and reported as successful.

• npx vitest run apps/cli/ai apps/cli/lib/tests/wp-cli-post-content.test.ts passes. Lint passes, and the typecheck shows only the existing errors in commands/export.ts and commands/push.ts.

Pre-merge Checklist

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

[wpmobilebot]

📊 Performance Test Results

Comparing f028cd9 vs trunk

app-size

Metric	trunk	f028cd9	Diff	Change
App Size (Mac)	940.68 MB	940.68 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	f028cd9	Diff	Change
load	1250 ms	1228 ms	22 ms	⚪ 0.0%

site-startup

Metric	trunk	f028cd9	Diff	Change
siteCreation	7537 ms	7543 ms	+6 ms	⚪ 0.0%
siteStartup	4376 ms	4366 ms	10 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

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