Without an after-separator state, the new unknown-flag guard rejected
flag-shaped prompts (`omp -p -- --explain-this`): the loop dropped the
`--` token and then re-validated `--explain-this`, recorded it in
`unrecognizedFlags`, and exited 2.
parseArgs now flips a `sawSeparator` latch on `--` and short-circuits
the remaining tokens straight into `messages` — no built-in dispatch,
no extension match, no `@file` expansion. Two regression tests cover
the flag-shaped and `@`-prefixed cases.
Refs #2459
Bare `omp --list-models` (or any other stale/typoed --flag) was silently
consumed by `parseArgs` and the agent went on to start a real session,
connect to the configured MCP servers, and hang waiting on the model.
Any positional after the unknown flag was reinterpreted as the initial
prompt, so a documentation drift turned into an unintended LLM invocation.
`parseArgs` now tracks flag-shaped tokens that did not match any built-in
or extension-registered flag in a new `unrecognizedFlags: string[]` field,
and `reportUnrecognizedFlags` prints a clean `Error: unknown flag(s): …`
line plus the `--help` hint. `runRootCommand` invokes the helper right
after the post-extension reparse and `process.exit(2)`s before any
session, MCP, or initial-message work runs.
The validation is gated on the extension-aware reparse, so extension
flags (`--spawn-peer`, `--headless`, `--plan`, …) still pass through
the same way `applyExtensionFlags` already handles them. `-` (stdin
marker) and `--` (POSIX separator) are deliberately allowed through.
Fixes#2459
roboomp