Why Is “Crush” So Severely Limited – and What’s the Point?

[Gaetner84]

I seriously wonder why Crush is so heavily restricted compared to other AI CLI tools like Claude CLI, Gemini CLI, or even its predecessor OpenCode. It’s completely counterproductive that essential functionality like automatically installing missing packages is disabled.

In technical workflows—whether it’s scripting, debugging, or building quick proof-of-concepts—it’s crucial that the AI can act autonomously and take care of its own environment. Having to switch tools, manually install dependencies, and then jump back into the conversation is not only inefficient, it’s frustrating.

Other platforms have figured this out: Claude can suggest and install packages, Gemini CLI can interact directly with the system, and even OpenCode had this capability already built in. Crush, however, has taken a step backward—allegedly in the name of security, but let’s be honest: it just feels like an unnecessary limitation that breaks the user flow.

Without the ability to take action on simple requests like pip install or apt-get, Crush becomes a tool that’s working against the developer, not with them. That's not progress—it’s regression.

My verdict: As it stands, Crush is unfortunately unusable for my workflow. Maybe I’ll check back in a few weeks or months to see if things have improved, but right now it’s simply not competitive.

I’ll leave you with this:

“Progress isn’t built on limitations—it’s built on empowerment.”

[emanuelturis]

I'm a user, and honestly wondering wdym by this? Crush allows for bash commands to be run, both in --yolo mode without having to accept permissions or without it. What's the limitation exactly?

[Gaetner84]

Hey @emanuelturis, @poblin-orange – thanks for your input!

You're both absolutely right that using sudo isn't always the best idea, especially in shared or security-critical environments. But I think we might be talking past each other a bit here — I'm not asking for a general "bypass sudo" mechanism. What I'm really advocating for is giving developers and researchers a choice — the ability to deliberately unlock elevated actions when they want and when it's appropriate.

In my case, I’m running Crush inside a Docker container, where the environment is fully sandboxed yet flexible. In this setup, it's completely safe and intentional to allow the AI (or agent) to install tools, modify scripts, or fetch extensions on its own — because it's operating in a tightly controlled context.

When building systems with AI-driven dev agents — for example, with roles like Operator, Security Monitor, or Builder — a certain level of autonomy is essential to make meaningful progress. I’m currently working on such a setup, where agents are assigned specific task domains and need the ability to install or configure tools independently. For this, it would be extremely helpful if Crush supported something like an explicit --allow-elevated or --trusted-mode flag, enabling a secure yet flexible way to grant such permissions.

The current limitation — where even --yolo mode or running as root doesn’t allow for apt, pacman, or even pip install — is a real blocker in these kinds of workflows. I understand the motivation (security!), but here’s the key: trust and control are not mutually exclusive. Developers and advanced users should be empowered to decide how the system is used in their specific environment.

To sum it up:
I'm not asking for Crush to be root by default — I'm asking for an optional, consciously activated flexibility layer. Especially in environments like Docker or Devbox, where elevated access is safe and expected.

Thanks for listening & best regards,
Gaetner84

[givensuman]

@emanuelturis, you’re correct that Crush can run Bash commands, even in --yolo mode with -y. But the core problem is: Crush cannot install any packages at all, not even in --yolo mode, because it lacks sudo privileges and can’t interact with package managers like pacman. This forces us to manually handle package installations ourselves, which is a major hassle. Meanwhile, tools like Gemini ...

wanting an LLM to be root on your system is such an L take lmao

[christophberger]

@givensuman If your system is in a container, a micro VM, or even a Unikernel, an LLM can be super duper root and nothing bad happens. If the LLM screws everything up, you throw away the whole thing and let it start over.

@Gaetner84 Would the MCP server container-use be suitable for–maybe–achieving some of the tasks your agents needs to do? I'm new to container-use, but I guess you could make everything run by root inside.

Update: please ignore, I overlooked this:

running as root doesn’t allow for apt, pacman, or even pip install

[givensuman]

@givensuman If your system is in a container, a micro VM, or even a Unikernel, an LLM can be super duper root and nothing bad happens. If the LLM screws everything up, you throw away the whole thing and let it start over.

I don't relate to the use case where you're using containerized environments but don't have the ability to modify packages.

Crush can edit a Dockerfile, can it not?

[bendavis78]

When working with docker, I have crush run outside the container. If you set up your CRUSH.md properly, it will know to use docker compose exec or docker compose run --entrypoint to get a shell inside a container if it needs to inspect anything. If you MUST have it run in a containerized environment, you can mount the docker socket and have it run these docker commands from within the container.

[christophberger]

FWIW, OpenCode is not a predecessor in the sense that it has been superseded by Crush. The two projects parted ways (after Charm hired OpenCode's main developer) and OpenCode lives here now.

[notwedtm]

Did you know your link points to the MCP docs?

[christophberger]

Dang! Wrong link in the paste buffer. Thanks, fixed.

[taf2]

[Askath]

That seems to be an issue with the model.
I have never had any problems with running bash commands but then again I mostly use gemini 2.5 flash or gpt-oss now

[bendavis78]

Never had a problem with this myself., but then again I'm using the git mcp which makes it simple.

[taf2]

i just ran it and pointed it to llama.cpp server running qwen3... i got this result asking it to run git status... seemed simple enough.. i then tried openai models and antrhopic models all gave me identical results... so i was wondering is it limited in what bash commands it can execute?

[Askath]

no Issues for me. I dont have any MCP installed either

[meowgorithm]

Hi! Thanks for all the commentary here. It’s helpful seeing both the positive and critical feedback: thank you for both. I’m going to close this thread now since it seems to have run its course, but we’ll keep the points raised here in mind as we continue developing Crush.

[keithy]

Its not even configurable?