fix(agents): quarantine invalid session custom tools#89006
Conversation
|
Codex review: found issues before merge. Reviewed June 27, 2026, 8:38 AM ET / 12:38 UTC. Summary PR surface: Source +283, Tests +177. Total +460 across 3 files. Reproducibility: yes. Current main directly reads SDK custom-tool names in Review metrics: 1 noteworthy metric.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Land one refreshed canonical session-tool snapshot/quarantine implementation that guards SDK and extension registration boundaries before unsafe reads, preserves valid tools, and explicitly accepts the fail-closed compatibility impact. Do we have a high-confidence way to reproduce the issue? Yes. Current main directly reads SDK custom-tool names in Is this the best way to solve the issue? No as written. The SDK-side mitigation is plausible, but the extension-side fix belongs at registration/snapshot ingress or should be narrowed out of this PR before merge. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against c5d34c8376f8. Label changesLabel justifications:
Evidence reviewedPR surface: Source +283, Tests +177. Total +460 across 3 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
|
|
Closing this fuzz-only hardening PR. The failure is constructed with hostile in-process objects, throwing getters, or similarly malformed metadata; there is no linked production report or external contract requiring that state. The patch spreads fail-soft handling through consumers and adds substantial branches/tests for a synthetic case instead of validating once at the real registration or parsing boundary. If an observed plugin/provider failure demonstrates that malformed external data can cross a supported boundary, please open a focused issue with the real payload and stack. The right fix would be canonical boundary validation with diagnostics, not per-consumer fallback behavior. Thanks for exploring the surface. |
Summary
AgentSession.refreshToolRegistryand whether the diagnostic surface is the right place to report rejected extension tools.Linked context
Closes #
Related #88994
Was this requested by a maintainer or owner?
Maintainer fuzzing follow-up for unsupported runtime/tool schema hardening.
Real behavior proof (required for external PRs)
node scripts/run-vitest.mjs src/agents/sessions/sdk.test.ts --reporter=dotOPENCLAW_OXLINT_SKIP_LOCK=1 node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.json src/agents/sessions/agent-session.ts src/agents/sessions/sdk.ts src/agents/sessions/sdk.test.ts./node_modules/.bin/oxfmt --check --threads=1 src/agents/sessions/agent-session.ts src/agents/sessions/sdk.ts src/agents/sessions/sdk.test.tsgit diff --check origin/main...HEADnode scripts/crabbox-wrapper.mjs run --provider aws --idle-timeout 90m --ttl 240m --timing-json --shell -- "env OPENCLAW_CHECK_CHANGED_REMOTE_CHILD=1 OPENCLAW_CHANGED_LANES_RAW_SYNC=1 corepack pnpm check:changed"1 passedfile and12 passedtests; oxlint reportedFound 0 warnings and 0 errors; oxfmt reported all matched files use the correct format; AWS Crabbox runrun_fc68d25ad837on leasecbx_9ebbab4a3dfbexited0withcheck:changedlanescore, coreTests.Tests and validation
Which commands did you run?
node scripts/run-vitest.mjs src/agents/sessions/sdk.test.ts --reporter=dotOPENCLAW_OXLINT_SKIP_LOCK=1 node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.json src/agents/sessions/agent-session.ts src/agents/sessions/sdk.ts src/agents/sessions/sdk.test.ts./node_modules/.bin/oxfmt --check --threads=1 src/agents/sessions/agent-session.ts src/agents/sessions/sdk.ts src/agents/sessions/sdk.test.tsgit diff --check origin/main...HEADnode scripts/crabbox-wrapper.mjs run --provider aws --idle-timeout 90m --ttl 240m --timing-json --shell -- "env OPENCLAW_CHECK_CHANGED_REMOTE_CHILD=1 OPENCLAW_CHANGED_LANES_RAW_SYNC=1 corepack pnpm check:changed"What regression coverage was added or updated?
namegetter does not crash startup.What failed before this fix, if known?
Session custom tools could enter the registry without the runtime-compatible schema filter used by assistant/model tool projection.
If no test was added, why not?
Tests were added.
Risk checklist
Did user-visible behavior change? (
Yes/No)Yes.
Did config, environment, or migration behavior change? (
Yes/No)No.
Did security, auth, secrets, network, or tool execution behavior change? (
Yes/No)Yes.
What is the highest-risk area?
Accidentally rejecting valid custom tools while quarantining bad definitions.
How is that risk mitigated?
The tests cover valid SDK tools, extension tools, method-backed tools, disabled tools, and client tools with omitted parameter schemas. The filter reuses the existing runtime-compatible tool projection instead of inventing a second schema policy.
Current review state
What is the next action?
Maintainer review and CI.
What is still waiting on author, maintainer, CI, or external proof?
CI after the draft PR opens.
Which bot or reviewer comments were addressed?
Local autoreview found and the patch addressed three issues before PR creation: method receivers are preserved, disabled tools are not inspected, and client tools without parameter schemas remain active. Final autoreview was clean.
AI-assisted: yes.