bug: unknown/misspelled flags are silently dropped instead of erroring

[NickCrews]

First, thanks for this great package. I think this is a very good solution for agents.
I am using it in https://github.com/NickCrews/van-openapi: I get claude to reverse engineer a platform's API once,
write it down in a spec, and then I get a CLI, language SDKs, MCP, docs, fuzzing and testing, etc all out of that.

I just found this bug when using ocli on that project. Here is a .zip of the full repro, what follows is just a description of the bug.

Summary

Version tested: 0.1.17

When an OpenAPI query parameter has a name starting with $ (e.g. $expand,
a common OData convention used by APIs like NGP VAN), ocli requires the
flag to be passed as --$expand on the command line. This is a bit
unusual, but is at least documented correctly in --help output.

The bug: if a user passes the "natural" spelling --expand instead (missing
the $), ocli does not error, does not warn, and does not
include the parameter in the request at all. It just silently drops it and
sends the request as if --expand had never been typed. The command exits
0 and returns a normal-looking (but incomplete) response, which is very
hard to notice — you only find out something's wrong when a field you
expected to be populated comes back null.

Expected behavior: an unrecognized flag like --expand (when the command
only defines --$expand) should cause yargs/ocli to error out (e.g.
"Unknown argument: expand"), the same way it (presumably) would for any
other unrecognized flag.

Repro contents

• openapi.json — a minimal spec with one GET operation that takes a
  $expand query param.
• mock-server.js — a tiny Node HTTP server standing in for a real API. It
  logs the raw querystring it receives and only returns parts in the
  response if $expand=parts was actually sent.
• run-repro.sh — starts the mock server, registers an ocli profile
  pointing at it, and runs the same command twice: once with --expand
  (wrong) and once with --$expand (correct per --help).

No network access or real API credentials needed — everything runs against
localhost.

Steps to reproduce

npm install -g openapi-to-cli   # or: npx -y openapi-to-cli ...
cd ocli-expand-bug-repro
bash run-repro.sh

Actual output

### ocli --help for the command ###
ocli widgets_id

Get a widget by id

Options:
      --id           (required)                                              [string ] [required]
      --$expand      (optional) ... Valid values: parts.                     [string ]
      --profile, -p  (optional) ...                                          [string ]
  -h, --help     Show help                                                   [boolean]

### call with --expand (WRONG flag name) ###
{
  "id": "widget-1",
  "name": "Example Widget",
  "parts": null
}

### call with --$expand (correct flag name per --help) ###
{
  "id": "widget-1",
  "name": "Example Widget",
  "parts": [
    "bolt",
    "nut",
    "washer"
  ]
}

### mock server log (what querystring was actually sent) ###
[mock-server] GET /widgets/widget-1  -> $expand=null
[mock-server] GET /widgets/widget-1?%24expand=parts  -> $expand=parts

The server log makes it clear: the --expand parts invocation sent no
querystring at all. ocli swallowed the flag instead of rejecting it or
forwarding it.

Expected output

Either:

1. ocli errors on --expand because only --$expand is a defined option
   for this command (preferred — matches normal yargs "unknown argument"
   behavior), or
2. ocli treats --expand as an alias for --$expand (if that's the
   intended convenience), documented as such.

Silently accepting-and-ignoring is the one behavior that should be off the
table, since it produces a "successful" response that's quietly wrong.

Why this matters

Any OpenAPI spec using $-prefixed query params (OData-style APIs — VAN,
several other CRM/EMS platforms) hits this. Because the failure mode is
"looks like it worked, data is just missing," it's easy to mistake for the
API not having the data, rather than a typo'd flag.

Real-world trigger

Encountered while calling the NGP VAN API
(https://nickcrews.github.io/van-openapi/openapi.json) via a command like:

ocli people_vanId_get --vanId 12345678 --expand addresses

which returns "addresses": null with no error, instead of the expected
address list. The --help output for that command does show --$expand,
not --expand — but it's easy to miss the $ and easy for the CLI to
just silently no-op on the typo instead of catching it.

[NickCrews]

Update: I dug into this a bit more and found that this isn't specific to the $
character. ocli silently ignores all unknown flags.

For example, if you run the exact same command but pass --bogus value or
--typo true, it behaves identically:

  ocli widgets_id -p expandbug --id widget-1 --bogus value                     

This returns a 200 OK with parts: null (dropping the unknown flag completely
from the network request) and exits with code 0 without any warnings.

Because openapi-to-cli appears to use yargs for argument parsing, the root
cause is likely that .strict() mode is not enabled. Without strict mode, yargs
will happily parse and then ignore any flag it hasn't explicitly been told to
look for, which leads to this "silent failure" behavior for any typo'd flags.

Enabling .strict() in the yargs configuration would fix this globally for all
commands by causing it to throw an Unknown argument: expand error, stopping
the execution before an incomplete API request is ever made.