fix(exec): compute bashElevated in gateway agent path to fix followup elevated exec errors#14
Open
suboss87 wants to merge 52 commits into
Open
fix(exec): compute bashElevated in gateway agent path to fix followup elevated exec errors#14suboss87 wants to merge 52 commits into
suboss87 wants to merge 52 commits into
Conversation
…nt disabled-job loophole
… 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes openclaw#74646.
Root cause
runAgentAttemptinsrc/commands/agent.tsnever assembled abashElevated(
ExecElevatedDefaults) value before callingrunEmbeddedPiAgent. When anagent turn is spawned via
sendExecApprovalFollowup→callGatewayTool("agent", ...), the followup run has no elevated context, sodefaults?.elevatedisundefinedinsidebash-tools.exec.ts.The "enabled" gate check then fails unconditionally:
This happens even when the user has elevated exec properly configured, because
the value was simply never computed and passed in.
Fix
runAgentAttemptnow computesbashElevatedfrom the effective config beforeeach
runEmbeddedPiAgentcall:enabledreflects globaltools.elevated.enabledAND per-agentagents.list[].tools.elevated.enabled(both must be non-false).allowedistrueonly whenenabledis true ANDsenderIsOwneris true(admin-scope callers, i.e. CLI operators). Gateway tool calls use
WRITE_SCOPE, sosenderIsOwner=falsethere — elevated stays blocked withthe correct "allowFrom" gate error instead of the misleading "enabled" gate.
defaultLeveldefaults to"ask"matching the channel-originated path.Channel-originated paths (Telegram, Discord, etc.) already compute
bashElevatedvia
get-reply-directives.tswith full sender identity and are unaffected.Regression test
Five new cases in
src/commands/agent.test.tsunderdescribe("bashElevated defaults"):senderIsOwner=true+ elevated not configured → enabled=true, allowed=truesenderIsOwner=false→ enabled=true, allowed=falsesenderIsOwner=true+tools.elevated.enabled=false→ enabled=false, allowed=falsesenderIsOwner=true+tools.elevated.enabled=true→ enabled=true, allowed=truesenderIsOwner=false+tools.elevated.enabled=true→ enabled=true, allowed=falseAll five previously would have received
bashElevated=undefined; now theyreceive a properly shaped object, and the "enabled" gate no longer fires
spuriously.
Testing
Generated by Claude Code