Resumable dockerised aider wrapper to allow LLM free-roaming CLI access

[stefanmohl]

Issue

It would be really cool if we could use Aider for all sorts of system ops work as well as for writing code. To let an LLM lose in my system, I would require quite tight constraints on what I give it access to. One way to achieve that is to run aider in a docker container where only specific host directories or files are mapped into the container. That way you know exactly what the LLM has access to and gain some measure of control.

An issue with this is that you can only set what directories are mounted to the container when launching the container, you can't change bind-mounts on a running container. This means that the wrapper needs to be able to restart aider with new directories mounted from time to time, letting the user change what directories aider has access to. To restart aider transparently it needs to be possible to snapshot all it's state and reload it on startup. That probably requires quite a bit of work.

Version and model info

No response

[dwash96]

Hey, so we do publish a docker container for aider-ce:
https://hub.docker.com/r/dustinwashington/aider-ce

And I have a small little demo repo for using aider in docker here (this has extra stuff, e.g. an entire code editor):
https://github.com/dwash96/worker-0

But I think what's really needed for this is to be able to save named sessions to the file system for persistence and being able to reload them. Volume mounting would definitely have your back on that case

[stefanmohl]

Yes, a lot of the stuff that is needed is already there. It is dockerised, and it can execute shell commands. I am already able to manually set what files and directories I map into the aider container, so I can perform a specific task that way as long as I correctly predict what I should give aider access to. I need to convince aider to look at the bind-mountings I create rather than the system files in the container. It is possible to use aider like this as it is, it is just a bit cumbersome so it is still easier to write the commands yourself.

What I am suggesting is to make the experience nicer. It would be nicer if we had a wrapper that lets aider itself suggest access to new directories and files, then allows the user to accept those new mappings through a yes/no prompt. Maybe also something like /add? Straight /add is not possible with the current git root constraints which are good to keep, so maybe add an /access command? Regardless of how extra access is granted, the new directories and files have to be bind-mounted in which requires a restart of the container. It might also be useful to have an /ops mode with special built-in prompts for system-related work.

[dwash96]

I've added the relevant session commands for part of this, I am not sure what the workflow for looking into new mounts would be outside of the docker containers mounts all targeting children folders that aider is the parent of and letting say, navigator mode ls and grep it's why through

[stefanmohl]

I don't think it is possible to create new mounts in a running docker container, so you would need some wrapper that shuts down the old docker, sets the new mounts, then restarts the container. That is why you need to have the session save, so that when the docker comes back you can load the session so you are back where you were but now with new mounts.

[stefanmohl]

This is the kind of situation I would like to avoid: https://futurism.com/artificial-intelligence/google-ai-deletes-entire-drive

[dwash96]

With the deployment of 0.89.3, the published docker container along with proper volume mounting and session naming for session autosaving, should make it possible to configure a system that can perform this behavior especially if keeping a common session history is necessary. The documentation I am adding to the README is as follows:

docker pull dustinwashington/aider-ce
docker run \
  -it \
  --user $(id -u):$(id -g) \
  --volume $(pwd):/app dustinwashington/aider-ce \
  --volume $(pwd)/.aider.conf.yml:/.aider.conf.yml \
  --volume $(pwd)/.aider.env:/.aider/.env \
  --config /app/.aider.conf.yml

By adding a volume for the session saving path (under .aider/sessions/{session name}.json}, you can keep a session alive on the host machine while letting aider-ce run entirely inside the container's context for commands. The container's /app folder, is the folder that contains the contents you want aider to operate on

[stefanmohl]

Very cool! Very cool indeed!

[dwash96]

Nice, let me know if you need any more information on any configurations you need for this set up or if this all works for what you had in mind