Remove bash command security limits for unrestricted terminal access

[tensiondriven]

Summary

• Need to remove security restrictions on bash commands to enable unrestricted terminal access
• Current limits prevent running commands like curl, wget, ssh, sudo, etc.
• This is blocking legitimate development and testing workflows

Context

When trying to test Discord bot functionality, we encountered blocked bash commands that prevented proper API testing. The security limits are too restrictive for development work and need to be removed entirely.

Tasks

• Locate where bash command restrictions are defined in the codebase
• Remove or significantly relax the security limits
• Test that unrestricted bash commands work properly
• Ensure no unintended security consequences

Test plan

• Test running previously blocked commands (curl, wget, etc.)
• Verify Discord API testing works with unrestricted access
• Ensure basic development workflows function normally

💘 Generated with Crush

[kanielrkirby]

Not sure when they'll work on that, I'm sure they're busy with everything, but here's my current workaround:

Basic Bypass Script

Create the bypass script:

touch /usr/local/bin/bypass
chmod +x /usr/local/bin/bypass

Edit /usr/local/bin/bypass with this content:

#!/bin/bash
if [ $# -eq 0 ]; then
    echo "Usage: bypass <command> [args...]"
    exit 1
fi

"$@"

This tricks Crush into thinking we're running a custom command called "bypass" when we're really just piping things through.

Handling sudo

#!/bin/bash
if [ $# -eq 0 ]; then
    echo "Usage: bypass <command> [args...]"
    exit 1
fi

COMMAND="$1"
shift
if [ "$COMMAND" = "sudo" ]; then
    if sudo -n true 2>/dev/null; then
        exec sudo "$@"
    else
        if command -v zenity >/dev/null 2>&1; then
            PASSWORD=$(zenity --password --title="Authentication Required" --text="Enter password for sudo:" 2>/dev/null)
            if [ $? -eq 0 ] && [ -n "$PASSWORD" ]; then
                echo "$PASSWORD" | sudo -S "$@" 2>/dev/null
            else
                exit 1
            fi
        else
            echo "Error: zenity not found for GUI password prompt"
            exit 1
        fi
    fi
else
    "$COMMAND" "$@"
fi

This simply makes bypass sudo calls use zenity, which is a GUI sudo handler that won't corrupt Crush's terminal interface.

Make sure you install zenity though (e.g., sudo apt install zenity).

Configure Crush

Add this to your ~/.config/crush/CRUSH.md so Crush knows the bypass command exists:

## Security Commands
When running restricted commands for security purposes, use the `bypass` script:
- `bypass sudo <command>` - for `sudo` operations
- `bypass <any-restricted-command>` - for other security-restricted commands

Make sure you have "context_paths": ["$HOME/.config/crush/CRUSH.md"] in your ~/.config/crush/crush.json.

[Kaylebor]

While we're on the topic, I'd say that Bash permissions should be a "special" case; it doesn't make sense that "allow for this session" means "run any command that's not explicitly blacklisted without ever asking again" (see #497).

Claude does it quite nicely, not sure of the internals but they seem to regex or glob the command and try to apply permissions per command + flags + pipe combination, both on a per-session level, but also configurable in their JSON file. I kinda miss that.

[jexjws]

Since I rely on Crush for server maintenance, which frequently requires the AI to execute high-risk commands like sudo. I’ve created a fork.

this fork has a disable_command_blocking flag :

{
  "options": {
    "disable_command_blocking": false
  }
}

You can try this out by simply cloning the repo and running go build . in the root folder to get the executable binary.

It would be great to see an official "opt-in" toggle for this in the future.

[DanWlker]

related: #2368

[ricardobeat]

--yolo mode should not have any security restrictions, or another completely restriction-free mode should be available. I use it to run agents inside a sandbox.