fix: approval prompt misleading text for one-shot commands#102441
fix: approval prompt misleading text for one-shot commands#102441supyinjie-max wants to merge 1 commit into
Conversation
- Add unavailableReasons field to ExecApprovalRequestParams schema - Pass unavailableReasons through gateway server-methods - Parse unavailableReasons in UI app and component layers - Display reason-specific messaging for no-reusable-pattern case - Add i18n string allowAlwaysUnavailableOneShot Fixes issue openclaw#97069 where commands with shell redirection (e.g., openclaw --version 2>&1) showed misleading text claiming 'effective policy requires approval every time' when the real reason was the command being non-persistable.
|
Codex review: needs real behavior proof before merge. Reviewed July 9, 2026, 2:00 AM ET / 06:00 UTC. Summary PR surface: Source +39. Total +39 across 6 files. Reproducibility: yes. The linked issue gives concrete redirected-command steps/screenshots, and current source shows one-shot and ask-always causes collapse into the same missing Allow Always decision while renderers emit policy wording. Review metrics: 1 noteworthy metric.
Stored data model 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:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Land one canonical fix that carries the unavailable reason from allow-always persistence through request/tool details and every approval renderer, syncs UI i18n, and includes real prompt proof. Do we have a high-confidence way to reproduce the issue? Yes. The linked issue gives concrete redirected-command steps/screenshots, and current source shows one-shot and ask-always causes collapse into the same missing Allow Always decision while renderers emit policy wording. Is this the best way to solve the issue? No. A typed reason field is plausible, but this PR only consumes sender-provided reasons and does not update the real producers or sibling renderers, so it is not the narrow complete fix yet. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a3f00d32c914. Label changesLabel justifications:
Evidence reviewedPR surface: Source +39. Total +39 across 6 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
Review history (1 earlier review cycle)
|
|
This pull request has been automatically marked as stale due to inactivity. |
Summary
Fixes issue #97069 where commands with shell redirection showed misleading approval prompt text.
Problem
When a command includes shell redirection (e.g.,
openclaw --version 2>&1), the approval prompt displays misleading text claiming the policy requires approval every time, when actually the command is just non-persistable (one-shot).Solution
Added
unavailableReasonsplumbing through all layers to enable reason-specific messaging.Changes
Testing