cdm deploy crashes on a JSON parse before doing anything, if Foundry is installed

cdm deploy crashes on a JSON parse before doing anything, if Foundry is installed

Summary

cdm deploy dies during build-order detection with
SyntaxError: JSON Parse error: Unexpected EOF, before building or deploying
anything. It happens only when forge is on PATH. Removing
~/.foundry/bin from PATH makes the same command work.

The project has no Solidity at all — no .sol files, no foundry.toml, no
remappings.txt. It's three Rust/PVM contracts. So the Foundry probe runs
unconditionally, and its failure is fatal rather than skipped.

Reproduce

$ cdm --version
0.13.0

$ forge --version
forge Version: 1.1.0-stable

$ cdm deploy -n paseo
Registry   0xc1a73a4f93fde65b1cb1680baead248073566cb0
...
            onMsg(JSON.parse(e.data));
                       ^
SyntaxError: JSON Parse error: Unexpected EOF
      at _onMessage (/$bunfs/root/cdm-darwin-arm64:50077:29)
      at spawnSync (node:child_process:226:22)
      at runCommandSyncJson (/$bunfs/root/cdm-darwin-arm64:25787:27)
      at readFoundryConfig (/$bunfs/root/cdm-darwin-arm64:25801:36)
      at readFoundryImportRemappings (/$bunfs/root/cdm-darwin-arm64:25591:45)
      at attachSolidityDependencies (/$bunfs/root/cdm-darwin-arm64:25644:41)
      at detectBuildOrder (/$bunfs/root/cdm-darwin-arm64:51856:53)
      at precomputeBuildDisplay (/$bunfs/root/cdm-darwin-arm64:61624:33)
      at runDeployWithUI (/$bunfs/root/cdm-darwin-arm64:61662:58)
      at deployWithRegistry (/$bunfs/root/cdm-darwin-arm64:61904:43)
Bun v1.2.23 (macOS arm64)

Workaround that makes it succeed, unchanged otherwise:

PATH="$(echo "$PATH" | tr ':' '\n' | grep -v '\.foundry' | paste -sd: -)" cdm deploy -n paseo

It isn't Foundry returning bad output

forge config --json run standalone in the same directory is clean:

$ forge config --json | head -3
{
  "src": "src",
  "test": "test",
...
$ echo $?
0

Valid JSON, exit 0. So the parse failure isn't the subprocess's output.

Hypothesis (offered as such — you'll know better)

The thrown frame is _onMessage doing JSON.parse(e.data) — a WebSocket
message handler — with spawnSync directly beneath it. That reads like a
blocking-subprocess-versus-live-socket race rather than anything to do with
Foundry's output: runCommandSyncJson uses spawnSync, which blocks bun's event
loop; the chain WebSocket is already connected by this point (the registry
address is printed just above); when the loop resumes, a queued frame is
truncated and the socket's own JSON.parse throws.

If that's right, the Foundry probe is just the trigger — any spawnSync of
comparable duration while the RPC socket is open would do it, and the fix is
about where blocking calls sit relative to the connection rather than about
Foundry specifically.

Suggested fixes, in order of appeal

1. Don't probe Foundry when there's no Solidity to resolve. Gate
   attachSolidityDependencies on the workspace actually containing .sol
   sources (or a foundry.toml). Skips the whole class for Rust-only projects.
2. Do build-order detection before opening the chain connection, or use the
   async spawn, so a blocking subprocess can't starve the socket.
3. At minimum, wrap the probe so a failure degrades to "no remappings" instead of
   killing the deploy — a missing/odd Foundry install shouldn't be fatal to a
   project that never asked for Solidity support.

Environment

• cdm 0.13.0 (bun 1.2.23, macOS arm64)
• forge 1.1.0-stable
• -n paseo, registry 0xc1a73a4f93fde65b1cb1680baead248073566cb0
• workspace: 3 Rust/PVM contracts, zero Solidity

Trace detectBuildOrder through attachSolidityDependencies, readFoundryConfig, and runCommandSyncJson, then inspect the _onMessage JSON.parse frame from the reported stack. Reproduce with forge on PATH in a workspace containing no Solidity files, and compare behavior with forge unavailable. Done means Rust/PVM-only deploys no longer fail while Solidity projects retain dependency detection.