description: “Critical bug report: Bash tool approval grants not persisting to staged-tool-calls.json database”
date: 2026-03-11
severity: high
category: tool-safety
status: ready-to-submit
Bug Report: Bash Tool Approval Grants Not Persisting (Cascading Approval Loop)
Issue Summary
Bash tool approval grants are not being persisted to the approval database, causing every Bash command to require fresh approval regardless of prior approvals in the same conversation or previous conversations.
Severity: High — Makes Rebel unusable for workflows requiring multiple Bash commands
Scope: Bash tool only; MCP tools unaffected
Duration: 4+ days (7-11 March 2026), 18+ documented occurrences
Configuration: Tool Safety set to Balanced mode
Version: Rebel 0.4.15 (stable channel), macOS (darwin 24.6.0 arm64)
Reproduction Steps
- Set Tool Safety to Balanced mode (Settings → Tool Safety)
- In any conversation, trigger a Bash command (e.g.,
ls -la) - Approve the command when prompted
- Command executes successfully
- Trigger another Bash command (e.g.,
date) - Expected: Command runs without approval (trust inherited from step 3)
- Actual: Approval prompt appears again
Reproduction rate: 100% across all conversations, all agents (main and subagents), all Bash command types
Root Cause Analysis
Evidence from System Files
File inspected: ~/Library/Application Support/mindstone-rebel/staged-tool-calls.json (246KB)
Finding: Zero Bash tool entries in approval grant database despite 18+ Bash approvals over 4 days.
# MCP tools correctly saved (23 entries):
jq '.stagedCalls | group_by(.displayName) | map({tool: .[0].displayName, count: length})' \
staged-tool-calls.json
[
{"tool": "Search workspace emails", "count": 4},
{"tool": "manage workspace draft", "count": 3},
{"tool": "Granola list meetings", "count": 3},
# ... 12 more MCP tool entries
]
# Bash tool entries: 0
jq '.stagedCalls[] | select(.displayName == "Bash")' staged-tool-calls.json
# Returns: (empty)
Why This Breaks Approval Persistence
When a Bash command is triggered:
- PreToolUse callback checks
staged-tool-calls.jsonfor approval grants - Finds no Bash grant (because they’re never saved)
- Blocks command and requests approval
- User approves → command executes successfully
- Approval grant is NOT saved to
staged-tool-calls.json 
Next Bash command repeats from step 1
MCP tools work correctly because their approvals ARE being saved to the database.
Additional Diagnostic Evidence
Empty Approval Queues
# No stuck approvals blocking the system:
cat ~/Library/Application\ Support/mindstone-rebel/pending-tool-approvals.json
{
"version": 1,
"pendingApprovals": [],
"pendingMemoryApprovals": []
}
Approval System is Functional
- Approvals DO clear individual Bash commands
- Approved commands execute successfully
- MCP tool approvals persist correctly (no cascading prompts)
- Only Bash approval grants fail to persist
Impact on User Experience
Documented Occurrences (18 total over 4 days)
- 7 March: 4 occurrences (morning through afternoon)
- 8 March: 1 occurrence (trivial
opencommand blocked) - 9 March: 7 occurrences (multiple conversations, both main and subagents)
- 10 March: 5 occurrences (including diagnostic investigation)
- 11 March: 1 occurrence (bug report preparation)
User Workflow Disruption
Example workflow requiring 5 Bash commands (memory update skill):
- Find recent source files: approval required
- Find recent topic files: approval required
- Calculate date range: approval required
- Search file contents: approval required
- Format output: approval required
Result: 5 approval prompts for a single skill execution that should require zero approvals in Balanced mode.
Skills and Automations Affected
Any skill or automation using:
findcommands (file discovery)datecalculationsgrep/rg(content search)jq(JSON processing)- Shell scripts
- Git commands
- Node.js one-liners
Technical Analysis
Likely Code-Level Causes
-
Bash approval grant save call is missing — The code path that handles Bash approvals doesn’t call the function that persists grants to
staged-tool-calls.json -
Exception being silently swallowed — The save operation throws an error (wrong format, schema mismatch, etc.) but the exception handler swallows it without logging
-
Bash categorized differently — Bash may be using a different persistence mechanism (separate database, different file) that’s broken or not working
-
PreToolUse callback not checking Bash grants — The callback may be looking for Bash approvals in the wrong place or under the wrong key
Why MCP Tools Work
MCP tools successfully save approval grants with this structure:
{
"id": "...",
"sessionId": "...",
"turnId": "...",
"timestamp": 1773079300000,
"expiresAt": 1773165700000,
"status": "approved",
"displayName": "Search workspace emails to paulchristensen@gmail.com",
"toolCategory": "mcp",
"mcpPayload": { ... },
"riskLevel": "medium",
"reason": "...",
"allowPermanentTrust": true
}
Bash approvals should follow the same pattern but are completely absent from the database.
Suggested Investigation Steps
- Check Bash approval save call — Trace code path from approval grant to database persistence for Bash tool
- Add logging — Log every attempt to save approval grants (success/failure)
- Compare to MCP tool path — Identify where Bash diverges from working MCP approval flow
- Check error handlers — Look for swallowed exceptions in approval grant persistence
- Verify staged-tool-calls schema — Ensure Bash can serialise to the expected format
Workarounds
Temporary Solutions
- Switch to Permissive mode — Settings → Tool Safety → Permissive (disables all approval prompts)
- Manual approval for each command — Accept that Bash workflows require repeated approvals
- Use MCP tools instead — Where possible, use purpose-built MCP tools rather than Bash commands
Trade-offs
- Permissive mode: Removes safety layer for all tools (not just Bash)
- Manual approval: Severely degrades UX and workflow efficiency
- MCP tools: Not always available for needed operations (shell scripts, git, date maths, etc.)
Expected Behaviour (Balanced Mode)
According to Tool Safety documentation:
Balanced mode should:
- Block risky operations (destructive commands, sensitive file access)
- Request approval for first occurrence of risky action
- Remember approval and allow similar future operations
- NOT block every similar operation after approval (current Bash behaviour)
Current Bash behaviour matches Cautious mode (every operation requires approval), not Balanced mode.
System Context
Environment:
- App: Rebel 0.4.15 (stable channel)
- Platform: macOS 14.6.0 (darwin, arm64)
- Workspace:
/Users/paulchristensen/My drive (paulchristensen@gmail.com) (1)/Mindstone Rebel - Tool Safety: Balanced mode
- MCP Config:
~/Library/Application Support/mindstone-rebel/mcp/super-mcp-router.json
Connected MCP Packages (working correctly):
- GoogleWorkspace-paulchristensen-gmail-com
- Granola-paulchristensen-gmail-com
- Slack-previse
- RebelInbox, RebelAutomations, RebelCanvas, etc.
Request for Fix
This bug severely impacts workflows requiring:
- Memory updates (find/grep commands)
- Date calculations (shell maths)
- File discovery (find/ls)
- JSON processing (jq)
- Git operations
- Shell scripts
- Automation development/testing
Priority request: Fix Bash approval grant persistence to match working MCP tool behaviour.
Additional Information
Happy to provide:
- Session logs
- Full
staged-tool-calls.jsonexport - Screen recordings of approval cascade
- Additional diagnostic commands
Please let me know if you need any other information to reproduce or fix this issue.
Tracking: Documented in Chief-of-Staff/memory/topics/Rebel-Tool-Safety-Preferences.md with 18 occurrences over 4 days (7-11 March 2026).
Submission Instructions
Submit to: Mindstone Community Forum → Bug Reports category
Title: Critical Bug: Bash Tool Approval Grants Not Persisting (Cascading Approval Loop)
Tags: bug, tool-safety, bash, approvals, balanced-mode