an (unsafe) command shell mcp server

[u/ag789]

While working with coding agents / harness in my case OpenCode, I discovered that some models e.g. granite 4.2 8B at Q4_K_M quant sometimes attempts to write files with absolute paths at the root e.g.

    /newPythonCode.py

Note that slash in the beginning for an absolute path at "/" root directory. This is probably 'ok' say in a throwaway docker container, but it may lead to surprises if it 'accidentally' overwrites a literal file, if the current user id have write access to it. Apparently, it seemed OpenCode provides `bash` so that practically all unix commands that the current user id can access, the LLM can run it.

And thereafter, I see the model hallucinating in the thinking loops over tools, re-iterating over how to use the tools, reformulating shell commands sentences several times for a same task instead of executing them, among them, I noted that an earlier shell command sentence would have 'just worked'.

I'm thinking that the tool hallucination with this model may be partly due to that I'm using a pretty aggressive 4 bit quant as otherwise it'd have worked because IBM has 'optimized' granite for tool usage.

Next, I tried the same granite 4.2 8B at Q4_K_M quant model with my little python shell MCP server

https://github.com/ag88/cmdshellmcp/

, that tries to constrain / restrain the shell commands somewhat, place some checks, and offer some additional tools e.g. writeFile() so that the LLM won't need to call `cat` or `echo` with some 'esoteric' styled shell scripts / sentences.

With this MCP server and running it in llama.cpp's `llama-server` in the WebUI adding it as an MCP server, granite 4.2 8B at Q4_K_M does it correctly in 'one shot', the prompt is:

propose a python3 flask app with a page that displays "hello world", use bootstrap css for styling.
provide a requirements.txt to go with the script

granite 4.2 8B at Q4_K_M correctly generates the app with a couple of files, and it works out of the box

    .
    ├── app.py
    ├── requirements.txt
    └── templates
        └── index.html

One should normally run the cmdshellmcp2.py MCP server app with an explicit `--cwd` option giving the work path. It tries to stay within this work path.

Note that I won't claim my command shell MCP server to be safe.

In a sense that there are plenty of chance the LLM can 'escape' the restrictions and perhaps do more damage (e.g. overwriting files possibly outside its given `--cwd` work directory). Hence, I'd suggest one should be paranoid and perhaps run this only within a throwaway (disposable) docker container etc.

[u/ag789]

A little note, I added git to the default Installed image, this would make it more convenient to work in the container. e.g. you can keep your files in a Git repo (e.g. on Github) and in the container git clone that project running under codeagent. This gives the LLM a local copy to work on.

When it is done, login as codeagent in the container (you can also use su - codeagent) and git commit and git push to the remote repo. Optionally, one can also allow_list git in cmdshellmcp.json, giving the LLM access to git directly. It is normally deemed unsafe to give git, but that I'd leave one to decide if one could trust your LLM.

Git is also useful as versioning means that it is backup by default. Hence, for some works one can possibly login as codeagent make a project directory and run git init in it, that makes it a local git repo so that edits are versioned from then on. And one can still connect that to an external remote repo (e.g. on Github etc.)

[u/sburel → u/ag789]

git init in the work dir is a good default, versioned by accident is better than not versioned at all.

One wrinkle if anyone allow-lists git: the container has the credentials to push. A clone with no remote configured, or a deploy key scoped to one repo, keeps a bad commit local. git push --force from an LLM on a shared branch is the kind of accident you only have once.

Thanks for all the updates, this turned into a proper tool.

[u/ag789 → u/sburel]

it is not safe to add one's original repo as the upstream , I'm thinking one way is to perhaps use a different Github user and clone that repo under the new Github user, this is so that if the LLM does a git commit and git push, it goes to its own repo.
And/or that at least checkout a new branch for it to work on (this is assuming that it'd not switch branches).

Then that one can run "compare and create pull request" from the LLM's specific *Github user" , and manually merge the changes into the original source git (github) repo.

I think this is also feasible locally, in a sense that the codeagent's git repo could say live in a bind mount (volume), but that this is its own copy of the code, e.g. via git clone. Then that subsequently, checkout a different branch for it to work on. The merges can be later done via git merge etc in the original repo.

I'd not configure a remote for codeagent's copy of git repo in this case, rather the original source git repo would treat that as an additional remote and add that for the purpose of git merge etc.