Windows: source-checkout setup is unusable — CLI build fails on chmod, and dapi never completes the handshake (named pipes)

[alvarovegaromero]

Summary

Two independent defects make the source-checkout + dapi setup unusable on Windows. Both have to be fixed before dapi can talk to the app at all.

• OS: Windows 11
• Node: v22.21.0 · npm: 11.6.1
• dapi: 0.201.0, built from a source checkout (dapi on PATH is a junction into apps/cli)
• Setup: git clone → npm install → cp apps/web/.env.example apps/web/.env → npm run dev:desktop

---

Bug 1 — the CLI build script fails on Windows (chmod)

apps/cli/package.json ends its build with:

"build": "esbuild ... --outfile=dist/index.js && chmod +x dist/index.js"

On Windows that is:

'chmod' is not recognized as an internal or external command,
operable program or batch file.
npm error Lifecycle script `build` failed with error:
npm error code 1

npm run dev:desktop builds the CLI as its first step, so the whole dev stack aborts before Vite or Electron ever start.

chmod is only needed for the macOS/Homebrew symlink and should be a no-op where it does not apply:

"build": "esbuild ... --outfile=dist/index.js && node -e \"if(process.platform!=='win32')require('fs').chmodSync('dist/index.js',0o755)\""

---

Bug 2 — the CLI handshake never gets a reply on Windows named pipes

With the app running and the named pipe present (\\.\pipe\diffusion-studio), every command fails:

$ dapi context
Unexpected end of JSON input

apps/cli/src/cli-client.ts (requestConnection) does:

sock.on("connect", () => sock.end(JSON.stringify(handshake)));

and apps/desktop/src/cli-server.ts answers on the socket's end event.

On Windows named pipes a half-close does not survive: the pipe goes down as soon as the client ends its side, so the app's 'end' handler races a torn-down socket and sock.end(JSON.stringify(reply)) writes to a dead pipe. The CLI sees EOF with an empty buffer, hence JSON.parse("").

Minimal repro (no Diffusion Studio involved, Windows only)

import { createServer, connect } from "node:net";

const PIPE = "\\\\.\\pipe\\ds-halftest";

const srv = createServer({ allowHalfOpen: true }, (sock) => {
  let buf = "";
  sock.setEncoding("utf8");
  sock.on("data", (c) => (buf += c));
  sock.on("end", async () => {
    await new Promise((r) => setTimeout(r, 50)); // any async work
    if (!sock.destroyed) sock.end(JSON.stringify({ ok: true }));
  });
  sock.on("error", () => {});
});

srv.listen(PIPE, () => {
  const c = connect(PIPE);
  let got = "";
  c.setEncoding("utf8");
  c.on("data", (d) => (got += d));
  c.on("end", () => { console.log("reply:", JSON.stringify(got)); process.exit(0); });
  c.on("connect", () => c.end(JSON.stringify({ port: 1, token: "x" })));
});

Result on Windows: reply: "", and the server's 'end' handler never runs.

If the client writes without half-closing (c.write(...)) and the server processes the handshake on the first complete data chunk, the reply arrives correctly.

Suggested fix (works on all platforms)

• cli-client.ts: sock.write(...) instead of sock.end(...), letting the app close the socket after replying.
• cli-server.ts: parse the handshake from accumulated data as soon as it is complete, keeping the end handler as a fallback for peers that do half-close (macOS/Linux).

---

Also worth documenting

openProject only calls launchApp() when process.platform === "darwin", so on Windows dapi open cannot start the app — the user has to launch Diffusion Studio manually first. That is easy to miss when following the source-setup instructions.

Workaround for anyone hitting this today

npm run dev:desktop          # after patching the chmod line
# then, with the app running:
dapi context

[k9p5]

Thanks for the unusually thorough report — the repro script and the half-close analysis in particular. Bugs 1 and 2 were both real, and both are already fixed on main; the third item is the one that's still open, though the cause isn't quite what it looks like.

Your checkout is at dapi 0.201.0, which was tagged 2026-08-29 and superseded two days later. Current main is v0.206.0.

Bug 1 — chmod in the CLI build: fixed

Real at 0.201.0, and the fix is essentially the patch you proposed. Landed in 46cef22 (2026-09-16):

"build": "esbuild ... --outfile=dist/index.js && node -e \"process.platform !== 'win32' && require('node:fs').chmodSync('dist/index.js', 0o755)\""

Bug 2 — the named-pipe handshake: obsolete, transport replaced

Your diagnosis of the half-close race looks right, but it no longer applies: the named-pipe transport is gone. apps/desktop/src/cli-server.ts was removed in 059e1f6 (2026-09-03), and apps/cli/src/cli-client.ts has no socket code at all now. The CLI speaks MCP over Streamable HTTP on a fixed loopback port (http://127.0.0.1:3274/mcp). So there's no half-close to survive, and the JSON.parse("") symptom is gone too — a down app now surfaces as Diffusion Studio is not running. Launch the app first, then retry.

dapi open can't launch the app on Windows: still valid, keeping this open

This one survives on current main, so I'm narrowing the issue to it rather than closing.

The cause has moved, though. The process.platform === "darwin" check you found is gone — launchApp dispatches to launchWin32 now. But launchWin32 starts with:

if (!process.versions.electron) return Promise.resolve(false);

and then relaunches process.execPath. It only works when the CLI runs on the app's own Electron binary — i.e. through the dapi.cmd shim the installed app writes with ELECTRON_RUN_AS_NODE=1. A source checkout with dapi junctioned into apps/cli runs under plain Node, so launchApp returns false and dapi open can't start the app.

The asymmetry you sensed is genuine, just one level down: launchDarwin uses open -a "Diffusion Studio", which has no Electron guard and resolves the app by name, so a macOS source checkout can launch an installed app. Windows has no equivalent "find the installed exe" fallback. Fix is one of those two — a fallback that locates the install, or documenting the manual-launch step for Windows source checkouts, which the README doesn't currently cover.

To get unblocked

Re-pull main (or v0.206.0) and the chmod patch and the handshake failure both go away. You'll still need to start the app manually before dapi context until the above is fixed.

[alvarovegaromero]

Thanks — that's a great writeup, and the transport rewrite explains it. Re-pulling main now to confirm Bug 1 and Bug 2 are gone on v0.206.0; I'll report back if anything's off, but the Streamable-HTTP move makes the half-close moot by construction, so I expect it's clean.

On the remaining item (dapi open on a Windows source checkout): I'd lean toward the locate-the-installed-exe fallback over a doc note. launchDarwin gives macOS "just works" via open -a, and a README caveat leaves Windows a second-class path that people will keep re-filing. The Windows equivalent of "resolve by name" is cheap:

• electron-builder/NSIS per-user installs land at %LOCALAPPDATA%\Programs\<AppName>\<AppName>.exe, machine-wide at %ProgramFiles%\<AppName>\....
• Or read InstallLocation from HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\<AppName> (falling back to HKLM), or the App Paths key.

So launchWin32 could, when !process.versions.electron, spawn that located exe (detached) instead of bailing on process.execPath — mirroring the macOS behavior rather than depending on the dapi.cmd shim.

Happy to send a PR for that if it's the direction you want; otherwise a README note for the source-setup flow is a fine interim and I can do that instead. Either way, thanks for keeping the issue narrowed to this rather than closing it.