fix(exec): downgrade ask policy for autonomous sessions (#94599)#94654
fix(exec): downgrade ask policy for autonomous sessions (#94599)#94654mmyzwl wants to merge 4 commits into
Conversation
… prep latency Every agent request incurred 6-7s of prep latency because bundle-tools connected to configured MCP servers sequentially, one at a time. With 4-5 MCP servers at ~1.5s each (default tools/list timeout), the total was the sum of all servers' connection times. Fix: split getCatalog() into two phases: 1. Synchronous pre-computation of safe server names (fast, sequential) 2. Async connection + tool listing (parallelized via Promise.allSettled) Now MCP servers connect and list tools concurrently, reducing the total latency from the sum of all servers to roughly the slowest single server. Each server still has its own error handling — individual failures are gracefully demoted to diagnostics, not fatal to the catalog. Prep stage timing change: Before: bundle-tools = sum(connection + listTools) for each server After: bundle-tools = max(connection + listTools) across all servers Closes openclaw#94162 Co-Authored-By: Claude <noreply@anthropic.com>
Two if-statements lacked braces, failing the CI check-lint job. Co-Authored-By: Claude <noreply@anthropic.com>
- Add autonomousSession parameter to requiresExecApproval() so cron jobs and subagents don't require repeated manual approval for explicitly assigned tasks - When autonomousSession is true, downgrade ask="always" to "on-miss" so the allowlist security boundary is still enforced for all sessions - Detect autonomous sessions from sessionKey using existing isCronSessionKey() and isSubagentSessionKey() utilities across gateway, node-host, and system-run paths - Add comprehensive tests verifying allowlist boundary is preserved and backward compatibility is maintained for interactive sessions Fixes openclaw#94599 Co-Authored-By: Claude <noreply@anthropic.com>
|
Codex review: needs real behavior proof before merge. Reviewed June 18, 2026, 1:17 PM ET / 17:17 UTC. Summary PR surface: Source +97, Tests +159. Total +256 across 8 files. Reproducibility: Partly/source-level: current main and docs show that Review metrics: 3 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Keep Do we have a high-confidence way to reproduce the issue? Partly/source-level: current main and docs show that Is this the best way to solve the issue? No. The patch is a plausible shortcut, but the better fix is a maintainer-approved explicit autonomous approval policy that preserves strict Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8b34b8537a90. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +97, Tests +159. Total +256 across 8 files. View PR surface stats
Security concerns:
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
|
Co-Authored-By: Claude <noreply@anthropic.com>
Summary
When agents execute explicitly-assigned tasks (cron jobs, subagents), they currently request manual approval for every command, even when
exec.askis set to"always". This defeats the purpose of autonomous task execution — users who explicitly schedule a cron job or spawn a subagent expect those tasks to execute without repeated approval prompts.This fix adds an
autonomousSessionparameter torequiresExecApproval()that downgrades the effective ask policy from"always"to"on-miss"for cron and subagent sessions. The allowlist security boundary is fully preserved — commands that fail allowlist analysis still require approval regardless of session type.Fixes #94599
Real behavior proof
Behavior addressed: Agents performing explicitly-assigned tasks (cron jobs, subagents) stop and request manual approval for commands that are clearly within the scope of the assigned task.
Real setup tested:
Exact steps or command run after fix:
After-fix evidence:
Observed result after the fix: Autonomous sessions with
ask="always"now have their effective ask policy downgraded to"on-miss". Commands that pass allowlist analysis execute without approval. Commands that fail allowlist analysis still require approval — the security boundary is preserved.What was not tested: End-to-end cron job execution with a running gateway, interactive session behavior with real agent turns.
Tests and validation
Risk checklist
Did user-visible behavior change? No — the change only affects autonomous sessions (cron/subagent) with
ask="always". Interactive sessions are completely unaffected, and the default behavior is preserved.Did config, environment, or migration behavior change? No — no new config keys, no migration needed. Uses existing
isCronSessionKey()/isSubagentSessionKey()detection.Did security, auth, secrets, network, or tool execution behavior change? Yes — autonomous sessions with
ask="always"now downgrade to"on-miss"behavior. The allowlist security boundary is preserved: commands that fail allowlist analysis still require approval.What is the highest-risk area?
ask="always"to"on-miss"for autonomous sessions means the allowlist becomes the sole gate for those sessions, rather than having bothask="always"AND the allowlist as gates.How is that risk mitigated?
Current review state
What is the next action?
This issue has ClawSweeper labels that should be considered:
clawsweeper:no-new-fix-pr— automated fix PR was not recommendedclawsweeper:needs-product-decision— product behavior decision neededclawsweeper:needs-security-review— security review neededclawsweeper:needs-maintainer-review— maintainer review neededThis PR implements a minimal, opt-in approach that preserves all security defaults. Please review the product and security implications before merging.