Feature Request: Support for working inside Containers / Dev Containers (e.g., "Attach to Container")

[eduardolat]

Please explain the motivation behind the feature request.
I do almost all of my development work inside dev containers (similar to VS Code's remote container feature). The primary problem is that the Goose GUI currently only seems to recognize and open projects on my local machine's filesystem.

This means Goose is "outside" my actual development environment, which has all the correct tools, SDKs, and dependencies. To automate tasks effectively, Goose needs to be able to "see" and interact with the code and tools inside the container.

This feature would unlock the use of Goose for any developer who relies on containerized development environments, which is extremely common.

Describe the solution you'd like
The ideal solution would be a feature similar to VS Code's "Attach to Dev Container."

In the Goose GUI, I'd like to see:

• An option to "Open a directory inside a running container" (it could list the running containers).
• Or, a button (e.g., "Attach to Container") that allows Goose to connect to a selected running container.

Once attached, the Goose GUI would operate as if it were running inside that container, giving it access to the container's filesystem and shell for executing commands.

A key benefit of this "Attach" approach is that all models, extensions, and configurations can remain centralized and managed by the main Goose GUI on the host machine. This would allow LLM connections to be configured once, and Goose could then use those configurations to perform tasks inside any container, avoiding the need to reinstall and re-configure everything (like API keys) in every single dev container that gets spun up.

Describe alternatives you've considered
The main alternative I've considered is installing the Goose CLI inside the dev container.

While this technically works, it's very inconvenient. It completely bypasses the main GUI application, forcing me to use the terminal for everything, which defeats the purpose of having a powerful desktop app. It feels like a temporary workaround, not a proper solution.

AI generated image of what it might look like

Additional context
I believe this feature would perfectly fill a niche and be incredibly useful. Many modern development workflows are moving to containers to ensure consistency. Making Goose "container-aware" would be a massive productivity boost

This would be a great advantage for those who work with dev containers, but if it could be for containers in general (not just dev containers) it would be fantastic, as it would cover even more use cases

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

[DOsinga]

we have the building blocks to make this work, actually.

the way that goose works is that there is a "server" process and the desktop client. if you could run the server (goosed it is called) in the container, you could then connect the client to it.

it doesn't quite work though, since right now the client starts the server (yeah that's odd). in development mode we have the command

just debug-ui

that starts the UI in a mode that tries to connect to the server at a debug port though. default is 3000. so if you would use that script with the right port and start goosed on your container, I think we'd have all the pieces.

maybe you can give that a try and if it kinda works we can think of formalizing this?

[eduardolat]

This is super interesting; however, it would be really useful if the client could install/start the Goose server (goosed) inside the container and somehow synchronize the configurations, credentials, MCP, etc (to avoid having to configure them manually repeatedly).

There are a lot of people working inside containers, and right now there isn't a tool that takes them into account, not even OpenCode, Codex, ClaudeCode, etc.

This could be a good opportunity for Goose to reach a wider audience.

If there's a way I can contribute to this, please let me know

[jamadeo]

Another way to experiment with this today is to run goose's developer extension in the dev container. This means the filesystem and shell calls happen in the dev container, while goose's config, api keys, etc are still on the host. You can do this today without changes to goose by:

• starting your dev container
• copying the goosed binary into it
• adding a custom extension in goose with a command like npx -y @devcontainers/cli exec --workspace-folder /host/path/to/devcontainer-project /container/path/to/goosed mcp developer

To make it all "seamless" in goose we'd just need the ability to get the goose binary into the container (would need to download a build for the container OS if different from host) and a built-in extension entry to point to a devcontainer workspace.

[eduardolat]

After giving it some thought, I don't think it's necessary to install the goosed binary inside each container. It should be enough for the goosed instance running on the host machine to have the ability to execute commands within any container.

That way, without installing anything inside the container, the host's goosed instance could run commands like this:

This could be achieved with the following steps (executed as subprocesses or similar):

1. Check if Docker is available
2. List all running containers: docker ps --format "{{.Names}}"
3. Execute a command inside the container: docker exec -it <container_name_or_id> <command>

This way is totally transparent for the user and the container, it doesn't require any special software inside the container.

I'm not sure how this would behave in the context of MCP servers, but it's just an idea I wanted to share, what do you think?

[DOsinga]

I thinK @eduardolat that's what @jamadeo is describing more or less. the difference being that in his suggestion the extension itself would run in the container and just get instructions from goose as to what to run, instead of what you are getting at, where the developer extension executes instructions inside of a container. can you try the way @jamadeo describes it?

[jamadeo]

@eduardolat that would work for shell commands, but we'd need something else for file edits. goose could edit them on the host if mounted in the container, but the paths would look different, which could confuse the model

[eduardolat]

I proposed this to avoid having to install things in the container and do it agentless (like Ansible), which would also allow, for example, using Goose through SSH or other adapters. However, it is true that it can become more complex, and it might be simpler to just copy the binary to the container.

Just as a side note, to mitigate the problem of paths and the file system, we could create a File System interface and have Goose work through it. This way, we can implement a local adapter for that interface (using the host's file system) and a Docker adapter (which works with commands to the container like ls, cat, touch, etc.). Depending on how goose is working, it would use one adapter or the other, it would be more or less a virtual file system (an abstraction), basically, separating the functionality of goosed from the machine it runs on

I'm also going to try to create an extension that works as @jamadeo suggests and I'll share the results here (for containers in general, not just dev containers)

[eduardolat]

I created this script that automates the installation of the MCP developer through a MCP Wrapper inside Debian and Ubuntu based containers just like @jamadeo suggested

https://github.com/eduardolat/goosecontainer

You can check out the README and try running it yourself

It works quite well but it kinda feels like a hack since you have to change the container name in the extensions and there isn’t a picker like the directory one

You also have to open the Docker volume folder otherwise you can’t reference files using the at sign @ and that’s a bit annoying I think it would be nice to have a proper integration that lets you open the container and choose a folder in the same process kind of like a two step picker it would be awesome if that worked both in the CLI and the GUI

For now it’s usable that way but the DX could definitely be improved

[eduardolat]

Another thing I’ve noticed is that when the container is running with the developer container extension and the volume folder is open, Goose tells the model the paths from the chosen directory but inside the container those files might be in different paths so the model gets confused and doesn’t detect them correctly

[michaelneale]

so am a bit confused - this isn't really about the UI accessing a remote goosed, but the more agentless (ansible like! - i like that analogy) to a container right @eduardolat?

There is the container use MCP - which supplements the developer MCP (or can even replace it). which attempted to do this (sometimes did quite well) - but I think you want something more "vertically" integrated? I would suggest looking at the developer MCP itslef in goose, having a model of that where every command is ansible like, and then there is a parameter which is the container (not sure how we surface that up to the GUI level, but I am sure would be possible).