Ask an agent to create a post as a draft, and the one thing you do not expect is for it to go live. In version 1.4.2, that is exactly what could happen. Asking for a draft status when creating a post, page, or custom post type item did nothing, and the item published anyway, with the tool reporting success as if it had done what you asked. This release fixes that, along with two related permission gaps the same audit turned up, a custom post type bug in the same area, two WooCommerce update bugs, and a documentation gap that touched every tool in the catalog.
“Create a draft” was creating a live post
The bug sat in create-post, create-draft, create-page, and create-cpt-item. You could ask for a draft, and the status you asked for was ignored. The item was created and published, and the response came back looking like a success, because as far as the tool was concerned, it had succeeded: it had created the item you asked for, just not in the state you asked for.
This is the one worth sitting with, because it is exactly the scenario a lot of people set up specifically to avoid. If you followed our guide to letting an agent draft posts without touching anything live, you likely have a low-privilege agent user and force-to-draft switched on as a backstop, and those layers still held: a user without publish rights still could not publish, and force-to-draft still forced new content to draft regardless of what was asked. But if you were relying on the status field itself, on an admin-level account, or on any workflow where the explicit status request was the only thing standing between draft and live, this bug meant the setting you thought you were using was not doing anything.
All four abilities now honor the status you ask for, and refuse the request outright when the connected user does not have the capability to publish. Asking for a draft now gets you a draft, and asking to publish when your user cannot publish gets you a refusal, not a quiet upgrade to live.
Two more gaps caught in the same audit pass
Fixing the status bug meant going through every path that touches a post’s status, and that pass turned up two more issues, independent of the one above and of each other.
Scheduling was not being treated as publishing. A future-dated status let a contributor who could not publish get a post live anyway, on a delay, without ever holding the capability that is supposed to gate it. Scheduled and private statuses now require the same permission as publishing outright, closing that route.
Separately, editing the status of an already-existing item was checked against the wrong permission. That cut both ways: it could let some users set a status they had no business setting, and it could stop a contributor from making a routine edit to their own draft. The check now uses the capability that actually governs publishing for that post type, read from the post type’s own registered capability names instead of a generic guess.
Custom post types were quietly downgraded to draft
A related but separate bug affected custom post types specifically. A CPT ignored every status except publish, so a request for pending or private silently became a draft instead. If your workflow depends on a custom post type moving through a specific status, this is fixed: the status you ask for is now the status you get.
A WooCommerce order update was adding line items, not replacing them
Away from posts, two fixes landed in the WooCommerce integration, starting with order updates. Sending line_items to update an order was adding those items to what was already there instead of changing the order to match what you sent, and the order total quietly grew as a result. That is a bug, not a feature anyone was relying on. The fix adds an explicit add_line_items field, so a caller states plainly whether they mean to add to an order or replace its contents, and the old ambiguity around what line_items actually does is gone.
The product type field that got silently dropped
The second WooCommerce fix is on product updates. Sending a type when updating a product was discarded without any indication that it had been ignored, so a request to change a product’s type appeared to succeed while nothing actually changed. Now, sending a type that does not match the product returns an error naming the mismatch, instead of pretending the update worked.
What full parameter documentation makes possible
The last change in 1.4.2 is not a fix, it is a gap closed. Every input on every tool now documents itself: all 505 of them, up from three abilities that had full documentation before this release. That number is not a rounding error. It means an agent, or a developer building against these tools directly, was previously guessing at things like which fields replace a value and which merge into it, that prices are plain decimal strings and not formatted currency, that country and state fields want two-letter codes, and that writing to a meta key outside your allowlist gets refused rather than silently returning empty. None of that behavior changed in 1.4.2. What changed is that it is written down, on the tool itself, where an agent reads it before it guesses instead of after. A build check now fails if any tool input goes undocumented, so this cannot drift back once it is fixed. For the guards that stay in place no matter what a tool’s own inputs say, the safety controls cover those separately.
Updating to 1.4.2 gets you all of it: draft actually means draft, the two permission gaps around it are closed, custom post types keep the status you ask for, WooCommerce order and product updates behave the way their fields say they do, and every tool now tells you, and your agent, exactly what it expects. It shipped one day after 1.4.1’s standards-conformance fixes, and the two updates are worth taking together.