[Windows] Invalid inherited PATHEXT can break native child commands inside local agent sessions

[github-lover-9999]

Summary

On a packaged Windows installation, I traced repeated native-command failures inside a local-agent session to the environment passed from the daemon into the agent process.

The affected runtime environment contained:

PATHEXT=.CPL

instead of a normal Windows executable-extension list.

That value propagated into the agent and its nested shell/tool processes.

Under the affected environment, otherwise-normal native commands intermittently lost stdout/stderr or failed with the Windows status:

2147942632
0x800700e8
ERROR_NO_DATA

Normalizing PATHEXT before spawning the agent eliminated the failures in controlled tests.

The issue was reproduced and locally fixed on packaged 0.17.0.

I also checked 0.19.0; this specific agent-runtime PATHEXT normalization is still not present there.

Environment

• Windows 11
• packaged desktop build
• reproduced on 0.17.0
• checked against 0.19.0
• local CLI agent runtime
• failure occurs in child/nested native-command execution

No user-specific paths are required to reproduce the condition.

Root-cause evidence

The environment inherited by the daemon/agent contained:

PATHEXT=.CPL

The problematic value was preserved into nested agent commands.

A controlled runtime patch normalized PATHEXT on Windows only when the inherited value did not contain .EXE.

Conceptually:

if (process.platform === "win32") {
  const key =
    Object.keys(env).find(
      (name) => name.toLowerCase() === "pathext",
    ) ?? "PATHEXT";

  const current =
    typeof env[key] === "string"
      ? env[key]
      : "";

  if (!/\.exe/i.test(current)) {
    env[key] =
      ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC";
  }
}

This is included to describe the verified mitigation, not to prescribe the exact implementation.

Verification after normalization

The patched runtime passed:

• cmd echo ×3
• node --version ×3
• python --version ×3
• additional Node/Python one-shot commands
• failure → next-command recovery
• real cancellation / SIGTERM
• command after cancellation
• long no-output command followed by recovery
• 20 sequential command executions
• additional read-only smoke runs

The previous 0x800700e8 / missing-output behavior did not recur.

Expected behavior

Local-agent sessions launched from the packaged Windows application should receive a usable Windows executable environment even if the desktop launcher inherited a damaged or unusually narrow PATHEXT.

At minimum, .EXE should remain resolvable for nested native commands.

Related work

There is a related open PR, #6049, which improves Windows .cmd / .bat executable resolution when PATHEXT is stripped or narrowed.

This report is slightly different:

#6049:
host-side executable resolution

this issue:
the PATHEXT value propagated into the spawned agent runtime
and then into nested shell/native commands

The two fixes may be complementary.

Suggested regression test

Add a Windows runtime-env test equivalent to:

const env = createAgentRuntimeEnv(
  {
    PATH: "...",
    PATHEXT: ".CPL",
  },
  daemonUrl,
  token,
  nodeBin,
);

expect(
  Object.entries(env)
    .find(([key]) => key.toLowerCase() === "pathext")
    ?.[1],
).toMatch(/\.EXE/i);

The exact normalization policy is up to the maintainers.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @github-lover-9999!

✨ 🔥 Lit the spark.

🌱 Every contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hi @github-lover-9999 — thanks for the unusually tight Windows write-up. The distinction you called out vs. #6049 is helpful: that PR is hardening host-side executable resolution, while this report is about the runtime environment that gets handed from the daemon into the spawned agent session.

I checked the current daemon path here, and your diagnosis lines up with the code: createAgentRuntimeEnv() in apps/daemon/src/server.ts already pins the OD-specific vars and handles Windows Path casing, but it still forwards inherited PATHEXT into the agent runtime unchanged. So this looks like a real bug on our side, and the regression seam you suggested around apps/daemon/tests/runtimes/agent-runtime-env.test.ts is the right place to lock it down.

I’ve tagged this as bug + help wanted. If you want to open a PR for it, this looks like a nicely scoped fix: normalize PATHEXT on Windows before spawning the agent runtime, then add a regression test for a narrowed value like .CPL. The open #6049 still looks complementary rather than duplicate.

[lefarcen]

If anyone from the community wants to pick this up, feel free to comment /claim and take it on.
The fix looks nicely scoped around Windows agent-runtime env normalization plus a regression test.

[github-lover-9999]

/claim

I’m happy to take this on. I’ll keep the scope limited to the Windows PATHEXT runtime-environment fix and a focused regression test, separate from #6049 and the Antigravity adapter work.

[lefarcen]

Thanks for picking this up, @github-lover-9999 — and appreciate you keeping the scope cleanly separated from #6049.
Roughly how long do you think this will take: a few hours, 1–3 days, about a week, or longer?

[github-lover-9999]

Thanks! The fix is already implemented and published here: #6937. The PR contains the scoped Windows PATHEXT fix and regression tests, and is currently open as a draft awaiting review.

[lefarcen]

PR #6937 is up in draft with the Windows-side runtime-env normalization for narrowed PATHEXT values like .CPL, plus focused regression coverage around createAgentRuntimeEnv(). Keeping this issue open until that PR lands — #6049 still looks complementary here, while #6937 is specifically targeting the agent-runtime env path raised in this report.

[lefarcen]

Re-opening this issue for community contribution because linked PR #6937 has had no author activity.

The PR has been left open as draft so @github-lover-9999 can resume later, and others may /claim this issue if they want to take it on.