What happened?
When the [instruction] positional argument is placed immediately after -w/--workspace-root <path> and is the last token on the command line, auggie's CLI parser concatenates the prompt onto the workspace path value. The CLI then fails with a "workspace root … Directory does not exist" error before any server request is made, so the command exits 1 with no output.
Adding any further option after the positional (e.g. --max-turns 1) makes the bug disappear, which is what made it hard to spot. Passing the prompt via -i/--instruction instead also avoids it.
What did you expect to happen?
-w <path> should consume exactly one argument (the path), and the following positional should be parsed as the [instruction], regardless of whether more options follow.
Steps to reproduce
Minimal repro (macOS, zsh, but shell-independent — argv is identical):
mkdir -p /tmp/auggie-repro
# 1) Buggy form — prompt is the trailing positional after -w PATH
auggie -p -q -w /tmp/auggie-repro "say hi"
Observed output:
❌ Workspace root error: Directory does not exist
Path: /tmp/auggie-repro say hi
Please check that the directory exists and try again.
exit 1. Note the workspace path is /tmp/auggie-repro say hi — the prompt got joined onto the -w value.
Both of the following workarounds succeed against the same directory:
# 2) Works: any option after the positional
auggie -p -q -w /tmp/auggie-repro "say hi" --max-turns 1
# 3) Works: pass the prompt via -i instead of positional
auggie -p -q -w /tmp/auggie-repro -i "say hi"
Other permutations that work for comparison (same args, different order):
auggie "say hi" -p -q -w /tmp/auggie-repro # positional first
auggie -p -q --workspace-root=/tmp/auggie-repro "say hi" # = form
So the trigger is specifically: -w <path> followed by a positional that is the last token.
Auggie version
0.27.2 (commit 23e29db5)
Request ID
N/A — the failure happens during local CLI argument parsing, before any server request is issued, so no Request ID is generated. For reference, the working invocations (2) and (3) above produced Request IDs eabe522d-1d0c-4042-a1ed-b987807e4a74 and e6e6f452-a17d-4972-9189-dba8fd1b3773 respectively.
Environment details
Environment
- OS: macOS (darwin)
- Shell: zsh 5.9
- Tool/CLI version: auggie 0.27.2 (commit 23e29db5), Node v24.15.0
Anything else we need to know?
It looks like the option -w/--workspace-root is being treated as variadic / greedy when it is followed by a positional that is also the final argv entry. A safe regression test would be to assert that for argv ["-p", "-q", "-w", "DIR", "PROMPT"] the parsed workspace root is exactly "DIR" and the instruction is exactly "PROMPT".
Real-world impact: this is easy to miss because the buggy form succeeds at the shell level (auggie still prints to stderr, but a caller redirecting stderr to a log file just sees an empty stdout and exit 1).
What happened?
When the
[instruction]positional argument is placed immediately after-w/--workspace-root <path>and is the last token on the command line,auggie's CLI parser concatenates the prompt onto the workspace path value. The CLI then fails with a "workspace root … Directory does not exist" error before any server request is made, so the command exits 1 with no output.Adding any further option after the positional (e.g.
--max-turns 1) makes the bug disappear, which is what made it hard to spot. Passing the prompt via-i/--instructioninstead also avoids it.What did you expect to happen?
-w <path>should consume exactly one argument (the path), and the following positional should be parsed as the[instruction], regardless of whether more options follow.Steps to reproduce
Minimal repro (macOS, zsh, but shell-independent — argv is identical):
Observed output:
exit 1. Note the workspace path is/tmp/auggie-repro say hi— the prompt got joined onto the-wvalue.Both of the following workarounds succeed against the same directory:
Other permutations that work for comparison (same args, different order):
So the trigger is specifically:
-w <path>followed by a positional that is the last token.Auggie version
0.27.2 (commit 23e29db5)
Request ID
N/A — the failure happens during local CLI argument parsing, before any server request is issued, so no Request ID is generated. For reference, the working invocations (2) and (3) above produced Request IDs
eabe522d-1d0c-4042-a1ed-b987807e4a74ande6e6f452-a17d-4972-9189-dba8fd1b3773respectively.Environment details
Environment
Anything else we need to know?
It looks like the option
-w/--workspace-rootis being treated as variadic / greedy when it is followed by a positional that is also the final argv entry. A safe regression test would be to assert that for argv["-p", "-q", "-w", "DIR", "PROMPT"]the parsed workspace root is exactly"DIR"and the instruction is exactly"PROMPT".Real-world impact: this is easy to miss because the buggy form succeeds at the shell level (auggie still prints to stderr, but a caller redirecting stderr to a log file just sees an empty stdout and exit 1).