fix(cli): reject non-numeric --timeout-seconds instead of passing NaN downstream

[EazyHood]

What

--timeout-seconds 30s makes every MCP call fail instantly and report a timeout, while auth and broker calls keep working. This validates the flag at the edge and fixes the one unguarded timeout conversion.

Why

Number("30s") is NaN, and the two HTTP paths disagree about what to do with it:

• packages/core/lib/http.js:17 — Math.max(Math.ceil(Number(timeoutSeconds || 15) * 1000), 1000). NaN is falsy, so it falls back to 15. Safe by accident.
• packages/core/lib/mcp-client.js:145 — Math.max(Math.ceil(config.timeoutSeconds * 1000), 1000). Math.ceil(NaN) is NaN, Math.max(NaN, 1000) is NaN. No fallback.

Node does not throw on setTimeout(fn, NaN) — it warns and substitutes 1 ms:

TimeoutNaNWarning: NaN is not a number. Timeout duration was set to 1.

So requestJsonRpc aborts its own AbortController before the request leaves, and the user sees a timeout error.

Run through resolveRuntimeConfig as it is on main:

--timeout-seconds	config	mcp-client:145	http.js:17
"30"	30	30000	30000
"30s"	NaN	NaN	15000
"1m"	NaN	NaN	15000
(unset)	15	15000	15000

The asymmetry is what makes this expensive to diagnose. Broker and auth calls go through http.js and keep working, so calle auth status is fine. Every MCP call dies instantly and reports a timeout, which reads as "the MCP server is down" — so you look at the server, the network and the token, everywhere except a typo in your own flag.

How

Validate at the edge. A secondsOption(value, fallback, flag) helper in config.js, applied to the four second-valued options that share the Number(x || DEFAULT) shape (timeoutSeconds, pollTimeoutSeconds, minTtlSeconds, telemetryTimeoutSeconds). It keeps the || fallback exactly as before, so falsy values still take the default and nothing that works today changes:

--timeout-seconds expects a positive number of seconds, got "30s". Use "30", not "30s".

Guard the one line that drifted. mcp-client.js:145 now uses the same || default form as its three siblings. This is not a new convention — it is the only one of four that was missing it:

http.js:17	Number(timeoutSeconds || 15) — guarded
telemetry.js:123	Number(config.telemetryTimeoutSeconds || 1.5) — guarded
broker-client.js:157	Number(config.pollTimeoutSeconds || 300) — guarded
mcp-client.js:145	config.timeoutSeconds * 1000 — was not

Tests

Two added to packages/cli/test/cli.test.js: one asserting each of the four flags is rejected with its own name in the message, one asserting valid values and defaults are unaffected.

packages/cli    37 tests, 37 pass, 0 fail   (35 existing + 2 new)
packages/core   12 tests, 12 pass, 0 fail
packages/core   syntax check + tsc --strict: pass

Note for reviewers running this on Windows: packages/codex-plugin and packages/cursor-plugin fail their frontmatter checks, and pnpm run check fails with them. I verified those are pre-existing by stashing this branch and re-running against unmodified main — same failures. They are the CRLF issue that #70 addresses, and are unrelated to this change.

[Ray-56]

The NaN diagnosis is valid and the local CLI/Core checks and tests pass, but the shared validator introduces two correctness gaps and the release metadata is missing.

[P1] Preserve the existing --min-ttl-seconds 0 behavior. Current main resolves { minTtlSeconds: "0" } to numeric zero, which is useful for disabling the minimum remaining-lifetime window. This PR rejects it because all four settings share a strictly-positive validator. Please make the constraints option-specific: allow a non-negative value for min TTL while keeping timer/request durations positive, and add a regression test for zero.

[P2] Bound timer-backed values as well as checking that they are finite. Node sets any setTimeout delay greater than 2,147,483,647 ms to 1 ms, so a value such as --timeout-seconds 2147484 passes this validator and recreates the same immediate-abort failure class that the PR is intended to prevent. Add a maximum for timeout-backed settings or safely clamp/reject them, with a boundary test. Node documents this behavior here: https://nodejs.org/api/timers.html#settimeoutcallback-delay-args

[P2] Add patch changesets for both @call-e/cli and @call-e/core. Both published packages change behavior in this PR. Verify with pnpm run check:versions and both package dry-runs.

[EazyHood]

All three addressed.

[P1] The bounds are per option now, so --min-ttl-seconds 0 resolves to zero again while the timeout flags stay strictly positive. One thing your note surfaced that I had not spotted: the value was read as value || fallback, so a numeric 0 was falsy and got replaced by the default even before the validator saw it. That is fixed too, and both the string and numeric forms are covered.

[P2] Good catch on the 32-bit delay. Timer-backed durations are capped at 2147483 seconds, with a boundary test at the limit and one past it. --min-ttl-seconds never reaches a timer, so it is not capped, and a test pins that.

[P2] Patch changesets added for @call-e/cli and @call-e/core.

Reverting to the shared validator fails 3 of the 39 CLI tests, so the new ones do exercise the change. Core is 12/12 and check:versions is in sync.

One thing I could not verify: pnpm --filter @call-e/cli pack:dry-run does not run on my machine. The script is POSIX shell (tmpdir=$(mktemp -d) && trap ...) and cmd.exe answers 'tmpdir' is not recognized. It fails the same way on the branch without these commits, so it looks environmental rather than caused by the change, but I have not been able to confirm the CLI dry-run itself. The @call-e/core one runs fine.

[Ray-56]

The current head resolves all previous findings: @call-e/cli preserves both string and numeric min-TTL zero, timer-backed values are bounded below Node's maximum delay, and patch changesets are present for both @call-e/cli and @call-e/core. GitHub CI is green, the branch remains clean against the latest main, and local CLI/Core checks, tests, version validation, and package dry-runs all pass. I did not find another merge blocker.