Hey team — thanks for shipping the CLI, it's been genuinely useful in evaluation. Filing one feature request that surfaced during a stress-test on a real Windows workload.
Summary
On Windows, scenarios create and scenarios update fail for any scenario whose blueprint exceeds ~25KB, because --blueprint only accepts an inline argv value and Windows CreateProcess caps total argv length at ~32K UTF-16 characters. Real-world Make scenarios routinely exceed this.
Environment
- OS: Windows 11 Pro (26200)
- Shell: Git Bash (MSYS2 / MinGW)
- Node.js: v24.15.0
@makehq/cli: v1.3.1
Reproduction
export MAKE_API_KEY=<token>
export MAKE_ZONE=eu1.make.com
# Fetch any non-trivial scenario (e.g. 49 modules → ~75KB blueprint)
npx @makehq/cli scenarios get --scenario-id=<id> \
| node -e 'let d="";process.stdin.on("data",c=>d+=c);process.stdin.on("end",()=>{process.stdout.write(JSON.stringify(JSON.parse(d).blueprint))})' \
> bp.json
# Strip the webhook hook to avoid bind conflict on clone
# (omitted for brevity)
# Try to create a copy via CLI
npx @makehq/cli scenarios create \
--team-id=<tid> --folder-id=<fid> \
--scheduling='{"type":"immediately"}' \
--blueprint="$(cat bp.json)"Expected
Scenario created (or a normal Make API error surfaced).
Actual
/c/Program Files/nodejs/npx: line 65: /c/Program Files/nodejs/node.exe: Argument list too long
Bash fails before Node even launches — Windows refuses the CreateProcess call because argv is too long. Consistent, 100% reproducible at sizes >~30KB.
Workarounds attempted (all failed)
--blueprint=@path/to/file.json → CLI treats @path as literal JSON input → parse error--blueprint=- → parse error (literal - isn't JSON)--blueprint=@/dev/stdin → parse error (literal path passed through)- Piping to stdin without
--blueprint → CLI requires the flag
No workaround exists within the CLI. Only option is to fall back to direct API calls (curl / https.request), which defeats the adoption purpose.
Impact
Measured 2026-04-23 across 5 Make organizations (one evaluator's workload):
- 106 active scenarios scanned
- 64% (68/106) had blueprints over 25KB — CLI-unusable for writes
- Per-team breakdown: 55%–81% over limit
- Top-5 biggest scenarios ranged 240KB–365KB
So roughly two out of three real production scenarios are blocked from CLI writes on Windows. Most-affected scenarios are the most important ones — large ones are large because they carry a lot of business logic.
Proposed fix
Accept blueprint content from any of the following alternative sources — any one of them is enough:
--blueprint-file <path> — new flag, reads JSON from a file--blueprint=@<path> — @-prefix convention (curl's --data @file, kubectl, AWS CLI)--blueprint=- — read from stdin- Unadorned stdin when
--blueprint is omitted — detect via !process.stdin.isTTY
Any of these would bypass the argv limit on Windows and also improve ergonomics everywhere (no more shell substitution for large JSON). Same constraint applies to --scheduling, though scheduling payloads are usually small enough to sidestep the limit.
Adjacent observation (optional — separate issue if useful)
On Windows, every 4xx API response also triggers this assertion on stderr, after the real error text is already printed:
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76
Non-fatal — users can still parse the preceding Error [400]: ... line — but it looks alarming and suggests something in the bundled Node runtime's async cleanup is unhappy on Windows error paths. Observed 3/3 times on 4xx responses. Happy to file as a separate issue if you'd like to track it independently.
Thanks again for the CLI.
Hey team — thanks for shipping the CLI, it's been genuinely useful in evaluation. Filing one feature request that surfaced during a stress-test on a real Windows workload.
Summary
On Windows,
scenarios createandscenarios updatefail for any scenario whose blueprint exceeds ~25KB, because--blueprintonly accepts an inline argv value and WindowsCreateProcesscaps total argv length at ~32K UTF-16 characters. Real-world Make scenarios routinely exceed this.Environment
@makehq/cli: v1.3.1Reproduction
Expected
Scenario created (or a normal Make API error surfaced).
Actual
Bash fails before Node even launches — Windows refuses the
CreateProcesscall because argv is too long. Consistent, 100% reproducible at sizes >~30KB.Workarounds attempted (all failed)
--blueprint=@path/to/file.json→ CLI treats@pathas literal JSON input → parse error--blueprint=-→ parse error (literal-isn't JSON)--blueprint=@/dev/stdin→ parse error (literal path passed through)--blueprint→ CLI requires the flagNo workaround exists within the CLI. Only option is to fall back to direct API calls (curl /
https.request), which defeats the adoption purpose.Impact
Measured 2026-04-23 across 5 Make organizations (one evaluator's workload):
So roughly two out of three real production scenarios are blocked from CLI writes on Windows. Most-affected scenarios are the most important ones — large ones are large because they carry a lot of business logic.
Proposed fix
Accept blueprint content from any of the following alternative sources — any one of them is enough:
--blueprint-file <path>— new flag, reads JSON from a file--blueprint=@<path>—@-prefix convention (curl's--data @file, kubectl, AWS CLI)--blueprint=-— read from stdin--blueprintis omitted — detect via!process.stdin.isTTYAny of these would bypass the argv limit on Windows and also improve ergonomics everywhere (no more shell substitution for large JSON). Same constraint applies to
--scheduling, though scheduling payloads are usually small enough to sidestep the limit.Adjacent observation (optional — separate issue if useful)
On Windows, every 4xx API response also triggers this assertion on stderr, after the real error text is already printed:
Non-fatal — users can still parse the preceding
Error [400]: ...line — but it looks alarming and suggests something in the bundled Node runtime's async cleanup is unhappy on Windows error paths. Observed 3/3 times on 4xx responses. Happy to file as a separate issue if you'd like to track it independently.Thanks again for the CLI.