Skip to content

fix(exec): compute bashElevated in gateway agent path to fix followup elevated exec errors#14

Open
suboss87 wants to merge 52 commits into
mainfrom
fix/74646-elevated-exec-followup-missing-bash-elevated
Open

fix(exec): compute bashElevated in gateway agent path to fix followup elevated exec errors#14
suboss87 wants to merge 52 commits into
mainfrom
fix/74646-elevated-exec-followup-missing-bash-elevated

Conversation

@suboss87

@suboss87 suboss87 commented Apr 30, 2026

Copy link
Copy Markdown
Owner

Fixes openclaw#74646.

Root cause

runAgentAttempt in src/commands/agent.ts never assembled a bashElevated
(ExecElevatedDefaults) value before calling runEmbeddedPiAgent. When an
agent turn is spawned via sendExecApprovalFollowupcallGatewayTool("agent", ...), the followup run has no elevated context, so
defaults?.elevated is undefined inside bash-tools.exec.ts.

The "enabled" gate check then fails unconditionally:

elevated is not available right now (runtime=sandboxed).
Failing gates: enabled (tools.elevated.enabled / agents.list[].tools.elevated.enabled)

This happens even when the user has elevated exec properly configured, because
the value was simply never computed and passed in.

Fix

runAgentAttempt now computes bashElevated from the effective config before
each runEmbeddedPiAgent call:

  • enabled reflects global tools.elevated.enabled AND per-agent
    agents.list[].tools.elevated.enabled (both must be non-false).
  • allowed is true only when enabled is true AND senderIsOwner is true
    (admin-scope callers, i.e. CLI operators). Gateway tool calls use
    WRITE_SCOPE, so senderIsOwner=false there — elevated stays blocked with
    the correct "allowFrom" gate error instead of the misleading "enabled" gate.
  • defaultLevel defaults to "ask" matching the channel-originated path.

Channel-originated paths (Telegram, Discord, etc.) already compute bashElevated
via get-reply-directives.ts with full sender identity and are unaffected.

Regression test

Five new cases in src/commands/agent.test.ts under
describe("bashElevated defaults"):

  1. senderIsOwner=true + elevated not configured → enabled=true, allowed=true
  2. senderIsOwner=false → enabled=true, allowed=false
  3. senderIsOwner=true + tools.elevated.enabled=false → enabled=false, allowed=false
  4. senderIsOwner=true + tools.elevated.enabled=true → enabled=true, allowed=true
  5. senderIsOwner=false + tools.elevated.enabled=true → enabled=true, allowed=false

All five previously would have received bashElevated=undefined; now they
receive a properly shaped object, and the "enabled" gate no longer fires
spuriously.

Testing

pnpm tsgo   # zero errors
pnpm test   # 37 pass (1 pre-existing failure unrelated to this change)

Generated by Claude Code


Open in Devin Review

claude added 30 commits April 1, 2026 15:34
claude and others added 22 commits April 18, 2026 03:46
… elevated exec errors

When sendExecApprovalFollowup triggers a new agent turn via the gateway
agent handler, runAgentAttempt did not compute bashElevated. The exec
tool received elevatedDefaults=undefined, so elevatedDefaults?.enabled
evaluated as falsy and every elevated bash request failed with:

  elevated is not available right now (runtime=sandboxed).
  Failing gates: enabled (tools.elevated.enabled / ...)

The fix computes bashElevated from config in runAgentAttempt:
- enabled: respects tools.elevated.enabled and per-agent override
- allowed: true only when senderIsOwner=true (admin-scope callers);
  false for backend-initiated turns (like approval followups) that
  lack sender identity to verify allowFrom entries

This means CLI operator turns (senderIsOwner=true) now correctly
inherit elevated access, while gateway backend callbacks (senderIsOwner=
false, such as sendExecApprovalFollowup) correctly deny elevated with
the more accurate "allowFrom" gate instead of the misleading "enabled"
gate.

https://claude.ai/code/session_01L7RnR4Z5nQSj2NuMvc8dND

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.

Open in Devin Review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Elevated exec fails after approval callback in 2026.4.26

2 participants