goose icon indicating copy to clipboard operation
goose copied to clipboard

Execute background processes

Open nigelsim opened this issue 6 months ago • 1 comments

Please explain the motivation behind the feature request. When developing web services, it is necessary to run the server in order to test the output. This occurred for me when developing a Django app, and Goose went to start the Django server, and then just waited forever:

Great! Now let's test the application to see if everything works:
─── shell | developer ──────────────────────────
command: cd /home/nigel/src/goose-django && python manage.py runserver &


◓  Indexing imagination...                                                      

Describe the solution you'd like What has worked well in Kilo, is an option to allow to run in the background if a timeout is exceeded (this bit is an assumption). Or maybe have the process tool exposed with an option for the LLM to request it be run in the background, then have the user agree to this.

Describe alternatives you've considered I could add a context to ask the LLM to request I start and stop background processes, but this seems unnecessary.

Additional context

  • [x] I have verified this does not duplicate an existing feature request

nigelsim avatar Jun 08 '25 03:06 nigelsim

(Not a maintainer here, but I have been trying to contribute patches to the developer MCP server).

In my opinion the best approach for this (where you can) is to use containers. I've been trying hard to switch many of my projects to run in docker/podman, and then I have a Justfile which goose can run commands from, not just builds but also unit tests.

The core problem with classic & in the shell is - what happens it that process itself spawns other processes? Not at all an uncommon thing, and while today the developer shell uses kill_on_drop - that only affects the direct child, not subprocesses.

Outside of explicitly opting into a docker/podman style flow for servers, one thing we could do in the developer shell perhaps by default on Linux is teach it how to use systemd-run as a mechanism to spawn explicit background jobs. It's quite good at that! And a key advantage of systemd-run is that it solves the forking problem, and it makes it also easy to opt-in to partial containerization where needed.

cgwalters avatar Jun 08 '25 13:06 cgwalters

thanks @cgwalters - that is a good suggestion. do you think we should add this to the system prompt? or possibly add a tool to the developer extension (I know you think it is too fat already) to spawn and kill a process?

DOsinga avatar Aug 06 '25 13:08 DOsinga