[petebacondarwin]

Failed API responses can put validation details in the envelope's messages array. cf currently displays only errors, leaving users with an opaque identifier such as posture.api.parameter.missing and no explanation of which parameter is missing.

Render messages after errors in the same stderr report, without adding an [error] label to supplemental text that has no code. Preserve the full envelope and response metadata for success: false responses returned with HTTP 200, including envelopes without result, so their details reach the renderer too. Keep the fallback message concise when an envelope has no usable details. Successful-response notices and stdout output remain unchanged. Includes regression coverage and a patch changeset.

Validation:

• pnpm check
• 51 focused API client, error-rendering, and command tests covering error details, HTTP 200 failures, missing content-type headers, malformed or empty messages, supplemental text labels, and clean stdout.

[pkg-pr-new]

npm i https://pkg.pr.new/cf@377

commit: 98531ff

[ask-bonk]

LGTM

github run

[github-actions]

cf --help startup

	mean	stddev	min	max
PR	163.7 ms	3.4 ms	157.0 ms	169.8 ms
base	169.2 ms	2.9 ms	163.7 ms	173.0 ms

Δ (PR vs base): ↓ -5.5 ms (-3.3%)

Measured with hyperfine on ubuntu-latest (3 warmup runs, 20 timed runs). CI numbers carry ±a few ms of runner jitter; treat small deltas as noise.

[clanky-the-clanker]

✅ Approved — No problems found. Failed envelopes now reach the renderer as ApiError with the full body. The messages entries are shown after the errors, without a label, and stdout is unchanged.

_{The decision is advisory: this comment never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

🚀 Release: ✅ LGTM

Risk: Low. A patch changeset is right for a fix: change.

---

🔒 Security: ✅ LGTM

No security concerns. The extra API text only goes to stderr. Telemetry still extracts numeric error codes only.

---

📖 AGENTS.md: ✅ LGTM

This pull request does not change any agent instruction files. The change follows the repository's rule against per-code error switches in errors.ts: it renders whatever the API's messages array contains, with no product-specific mapping.

---

📋 Code Quality: ✅ LGTM

I found no defects in the changed code or in the code that calls it.

• Error type and body: unwrapEnvelope is only called from responseBody, which now passes the Response. Before this change, the plain Error thrown for a success: false envelope was caught in Client.send (api/client.ts:269-289) and re-wrapped as an ApiError with unknownResponse. That dropped the envelope body. The error is now an ApiError carrying body and rawResponse, so handleError and telemetry's extractErrorCodes both see the real envelope.
• Error message: Setting error.message again after construction removes the verbose Status code / Body text that ApiError's constructor adds.
• Envelopes without result: A success: false envelope with no result now throws instead of being returned as if it had succeeded. A successful envelope without result is still returned unchanged.
• Rendering: apiMessages drops malformed entries. [error] appears only on errors entries that have no code. Supplementary messages lines have no label, and the status tail is printed once, after the last entry.
• Tests and changeset: The tests cover HTTP 200 and 4xx failures, a missing content-type header, empty and malformed messages, the label rules, and clean stdout. A patch changeset is included.

---

⚡ Performance: ✅ LGTM

No performance concerns.

---

📝 Documentation: ✅ LGTM

The updated unwrapEnvelope doc comment matches the new behaviour. The changeset describes the change clearly.

---

_{Reviewed commit: 98531ff0}

[ask-bonk]

🤖 I've done a thorough review of your PR.

Adds rendering for supplementary API envelope messages and preserves failed 2xx envelope metadata.

1. Empty supplementary message strings suppress the concise fallback and render a blank error line. Posted an inline suggestion.

github run