fix(matrix): validate CLI numeric option ranges#92483
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 12, 2026, 11:37 AM ET / 15:37 UTC. Summary PR surface: Source +19, Tests +42. Total +61 across 2 files. Reproducibility: yes. at source level with high confidence: current main permits the negative values past integer parsing, and the PR supplies before-and-after command evidence for both paths. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Next step before merge
Security Review detailsBest possible solution: Land the plugin-local early validation so verification timeouts remain positive and initial sync limits remain non-negative without changing persisted Matrix configuration or normal command behavior. Do we have a high-confidence way to reproduce the issue? Yes, at source level with high confidence: current main permits the negative values past integer parsing, and the PR supplies before-and-after command evidence for both paths. Is this the best way to solve the issue? Yes. Validating once at the owning Matrix CLI boundary before runtime, configuration, or network-related work is the narrowest maintainable fix and preserves each option's distinct accepted range. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 3643de4ba7b6. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +19, Tests +42. Total +61 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
4e51ee9 to
d75f118
Compare
vincentkoc
left a comment
There was a problem hiding this comment.
Verified for maintainer merge.
Proof:
node scripts/run-vitest.mjs extensions/matrix/src/cli.test.ts --maxWorkers=1passed.- Autoreview clean: no accepted/actionable findings.
- Crabbox AWS
cbx_5c32f138ab3a/swift-lobster, runrun_6e133b8b82e7:OPENCLAW_CHECK_CHANGED_REMOTE_CHILD=1 OPENCLAW_CHANGED_LANES_RAW_SYNC=1 CI=1 corepack pnpm check:changedpassed. - Exact PR head
d75f118299029b0516311646276cd2d6582379c5: 129 success / 24 skipped / 1 neutral / 0 failures / 0 pending.
Review notes:
--initial-sync-limitnow validates before setup validation/config writes.--timeout-msnow validates before Matrix account-context resolution.- This is CLI numeric validation only; no SSRF, shell execution, credential, or network-policy surface changed.
Summary
matrix verify self --timeout-msnow requires a positive integer.matrix account add --initial-sync-limitnow rejects negative values while still allowing zero and positive integers.Linked context
Fixes #92482
Related: none.
Was this requested by a maintainer or owner? No; this came from local bug reproduction and is linked to the issue above.
Real behavior proof (required for external PRs)
OPENCLAW_CONFIG_PATHandOPENCLAW_STATE_DIR. The Matrix CLI source registration was invoked through Commander so the proof exercised the changed CLI code without touching my real config.matrix verify self --timeout-ms -1andmatrix account add ... --initial-sync-limit -1, using a temporary config with dummy Matrix values.--timeout-ms -1reached the verification path and producedCannot read properties of undefined (reading 'id');--initial-sync-limit -1did not fail at the CLI boundary.Tests and validation
node scripts/run-vitest.mjs extensions/matrix/src/cli.test.ts -t "rejects non-positive Matrix self-verification timeout values|rejects negative Matrix initial sync limits"node scripts/run-vitest.mjs extensions/matrix/src/cli.test.ts./node_modules/.bin/oxfmt extensions/matrix/src/cli.ts extensions/matrix/src/cli.test.ts --check./node_modules/.bin/tsc -p extensions/matrix/tsconfig.json --noEmitpnpm lint:extensionsgit diff --checkRegression coverage added for negative
--timeout-msand negative--initial-sync-limit.pnpm check:changedwas attempted, but localcrabboxfailed its basic--version/--helpsanity checks before reaching code checks.Risk checklist
Did user-visible behavior change? (
Yes/No)Yes. Invalid negative Matrix CLI values now fail earlier with clearer errors.
Did config, environment, or migration behavior change? (
Yes/No)No migration or persisted config shape change. Account setup now rejects an invalid explicit
--initial-sync-limit -1instead of letting downstream normalization treat it as absent.Did security, auth, secrets, network, or tool execution behavior change? (
Yes/No)No. The real-behavior proof uses dummy local values only; no secrets are required.
What is the highest-risk area?
Rejecting a value that previously slipped through.
How is that risk mitigated?
The accepted ranges match the downstream behavior: verification timeout must be positive; initial sync limit allows zero and positive integers but not negatives. Focused regression tests cover both boundaries.
Current review state
Ready for review. Nothing is currently waiting on the author.