question(shell): should Windows built-ins work inside parsed shell chains?

[ctharvey]

Question

I ran into a Windows shell-chain case and wanted to check the intended behavior before treating it as a bug.

Example:

type package.json | findstr verify

On Windows, type is a cmd.exe built-in, not a standalone executable. If Reasonix parses the chain and runs each segment directly with no shell, then the left side tries to spawn type and fails because there is no type.exe on PATH.

That may be expected, especially if the chain runner intentionally avoids invoking a shell for safety/control.

What I’m asking

Should parsed chains support Windows cmd.exe built-ins such as type, dir, and echo inside chain segments, or should users/models avoid those and use native tools like read_file / search_content instead?

Possible outcomes

Either seems reasonable:

• document that parsed chains do not invoke cmd.exe / shell built-ins, so Windows users should avoid type | findstr patterns
• or add Windows-specific handling so built-in segments can route through cmd.exe /c when needed

Notes

This is separate from the Windows backslash quoting issue. This question is only about shell built-ins inside parsed chains.

Non-goals

• no broad shell parser rewrite
• no shell: true behavior change unless intentionally chosen
• no filesystem tool changes
• no CHANGELOG.md

[esengine]

Thanks for checking before filing — this case is already handled. Every chain segment goes through prepareSpawn, which detects bare unresolved Windows names (type, dir, echo, ver, where, …) and routes them through cmd.exe /d /s /c chcp 65001 >nul & <cmd> (src/tools/shell.ts:522-529, test at tests/shell-tools.test.ts:729). The chain runner calls prepareSpawn per segment (src/tools/shell-chain.ts:401), so type package.json | findstr verify resolves end-to-end on Windows.

The in-pipe case isn't pinned by a test though — if you want to add one for dir | findstr foo on win32, that'd be a nice tightening. Otherwise I'll close as working-as-intended.

[esengine]

Closing as working-as-intended (see comment above). Reopen if you hit a case doesn't catch — extra test for the in-pipe variant always welcome.