[sentry-junior]

Refs #1564.

When a flag or positional parse function throws, Stricli wraps the error in ArgumentParseError and always exits with ExitCode.InvalidArgument (-4, which the shell sees as 252). So a ValidationError from one of our flag parsers loses its exit code. For example, sentry issue list --period bogus and sentry log list --sort sideways exit 252, but the exit code docs say a bad flag value exits 21. #1594 avoided this for target positionals by parsing them lazily inside func. Flag parsers still run in Stricli's scanner.

Changes:

• The @stricli/core patch adds an optional determineArgumentErrorExitCode application hook. Stricli calls it for each scanner error, and the first number it returns becomes the exit code. If the hook is unset or returns undefined, Stricli exits with InvalidArgument as before. The hook has a PATCH(getsentry/cli) marker, and check:patches now checks that it is present in both bundles.
• app.ts returns the wrapped CliError's exitCode from that hook. It also formats these errors with formatError, which handles format() and credential redaction. The Failed to parse "<input>" for <param>: prefix stays the same.

Errors that are not CliErrors keep exit code 252. This includes Stricli's own numberParser (--limit abc), unknown flags, and missing positionals. Parse-phase errors still don't go through reportCliError or the --json error output. Both are unchanged here.

via BYK.

--

View Junior Session in Sentry

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
sentry-local	Ready	Preview	Oct 23, 2026 11:53pm UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 85b8870. Configure here.}

[BYK]

At this point I'd prefer reverting to argument parser error for everything and accepting that or trying to wrap the stricli error class with ours if possible without patching it

[sentry-junior]

@BYK, I looked into fixing this without patching Stricli. I haven't pushed anything yet. Stricli maps every scanner error to ExitCode.InvalidArgument and passes our app nothing but the formatter (exceptionWhileParsingArguments), which gets no context. So any patch-free fix has to remap the exit code after run(). I see two ways to do that, and both have a cost:

1. Record the error in the formatter, then remap after run() in cli.ts and in both sdk-invoke.ts runners. This is small, but the recorded error lives in module-level state. Concurrent SDK run() calls could read each other's error and get the wrong exit code.
2. Wrap every flag and positional parse in buildCommand. The wrapper would record the CliError keyed by this.process (one per run, so no race) and rethrow it. The cost is that parser identity carries metadata: withCompletionTarget stores data on the function, and lazyParsers is a WeakSet of them. So the wrapper has to copy those over, and it touches every command's parameters.

Neither one is clearly better than keeping the patch, so I lean toward your first option: keep exit 252 for scanner-phase errors, document it, and close this PR. One question first: by "reverting to argument parser error for everything", do you also mean undoing #1594's lazy positionals, so that positional parse errors go back to 252 too? Or only leaving flags as they are on main?

[sentry-junior]

Closing in favor of #1655, which follows the review here: no Stricli patch. Argument parse errors exit 252 everywhere, including target positionals, and the docs now say so.