Hosted trustLockfile and vendored overrides appends corrupt a flow-style or ...-terminated pnpm-workspace.yaml while reporting success #400

[agent] Found by the scheduled pnpm bug-hunt routine (ledger #303).

Summary

When pnpm-workspace.yaml is valid YAML that isn't a plain block mapping (a whole-document flow mapping like {packages: [.]}, or a block mapping followed by the ... document-end marker), two edits append block-style lines after the last non-empty line and produce a file pnpm can't parse:

• scan --mode hosted appends trustLockfile: true (plan_workspace_trust).
• vendor appends an overrides: section (the "File exists without an overrides: section" branch).

Both commands exit 0 with status: success and list pnpm-workspace.yaml as rewritten. The next install of the committed checkout then fails.

Impact

After a "successful" hosted scan or vendor run, every later pnpm install in the repo (frozen or not) fails: pnpm 10/11 refuse to load the workspace file, and pnpm 12 fails the policy check or config load. CI breaks for the whole project, not only the patched package. Nothing warns or refuses beforehand, although the vendored path already refuses an inline overrides: mapping it can't edit (vendor_override_conflict), so a refusal pattern for this already exists.

Repro (hosted; needs a patch-API mock that serves a patched left-pad tarball)

mkdir proj && cd proj
echo '{"name":"proj","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
printf '{packages: [.]}\n' > pnpm-workspace.yaml       # or: printf "packages:\n  - '.'\n...\n"
pnpm install                                            # works on the original file
socket-patch scan --mode hosted --json --yes --api-url http://127.0.0.1:18731 --org test-org --api-token fake
#   -> exit 0, status success, rewrittenFiles [pnpm-lock.yaml, pnpm-workspace.yaml]
cat pnpm-workspace.yaml
#   {packages: [.]}
#   trustLockfile: true
pnpm install --frozen-lockfile
#   [ERROR] end of the stream or a document separator is expected (2:1)

Vendored: the same project with a staged .socket/manifest.json and blobs, socket-patch vendor --yes --offline → exit 0, applied, and the file becomes {packages: [.]}\noverrides:\n [email protected]: file:.socket/vendor/..., so the same parse error follows.

With ..., the appended lines land in a second YAML document: expected a single document in the stream, but found more on pnpm 10/11, and line 4 column 1: multiple YAML documents on pnpm 12.

Expected vs actual

• Expected: docs/ecosystems.md (npm hosted-mode notes) says that for root 9.0 locks the CLI "configures trustLockfile: true in pnpm-workspace.yaml". The code comment on plan_workspace_trust promises a line splice with "every other byte preserved". Both imply the result is still a workspace file pnpm loads. Where the splice can't produce valid YAML, the CLI should refuse with a clear code, as check_workspace_override already does for an inline overrides: mapping, or else edit the document correctly (insert before ..., or add the key inside the flow mapping).
• Actual: invalid YAML is written, the command reports success, and the next install fails.

OS × version (Linux, Node 22, main f6b7fb9)

The hosted pnpm 11 flow case first showed up in run 1 (2026-09-30) and reproduced again in this run. Released 4.0.0 (npm @socketsecurity/[email protected]) behaves the same on pnpm 11.27.0, so this isn't a new regression. macOS and Windows weren't probed (the edit is a pure string splice and doesn't depend on the OS).

Suspect code

• crates/socket-patch-cli/src/commands/scan/hosted.rs:386 (plan_workspace_trust, the append at :409)
• crates/socket-patch-core/src/vendor/pnpm_lock.rs:1794 (the overrides-section append in the workspace edit). check_workspace_override (~:1683) refuses only an inline overrides: line, not a flow document or ....