[Feature] Attach host volumes to container use (CWD + additional directories)

[luketych]

Summary

Allow container use to mount one or more host directories (read-write or read-only) into the running container.

Primary need: mount the current working directory and a second directory that stores prompts/configurations for LLM tools (e.g., Claude, OpenCode) used inside the container.

Motivation

When iterating with LLM tooling inside a Dagger-managed container, I need:

The project CWD mounted (code in/out).

A separate prompts/configs directory mounted (shared across projects).

Optionally, additional read-only mounts for datasets or model caches.

Right now, accomplishing multi-mount workflows requires bespoke SDK code or external wrappers. Native support in container use would make it trivial to adopt and script, and would align with the “fast inner loop” developer workflow.

Proposal

Add repeated --mount flags to container use:

Read-write by default

dagger container use
--mount "$(pwd):/work"
--mount "$HOME/llm/prompts:/prompts"
--workdir /work

Read-only mount

dagger container use
--mount "$HOME/datasets:/data:ro"

Flag format:
--mount :[:ro|rw]

Use cases

Run Claude/OpenCode (or other LLM tools) inside a container with:

/work = project CWD

/prompts = shared library of prompts/configs

Share a model cache or dataset directory across multiple projects/containers.

Mount dotfiles or toolchains read-only (e.g., /opt/tooling:ro).

[cwlbraa]

I'm confused by the command syntax you've proposed, i've never seen anyone invoke container-use like dagger container use -- is this some other workflow? do you want this on cu stdio (not env-specific, so i don't think that makes sense)

Writable bind mounts are probably not feasible due to both their absence in the dagger api and the way container-use builds up layered filesystems for each env -- all the file editing tools would need to be reimplemented to work inside the shell container instead of from the "outside" dagger API, and we'd lose the ability to track the history of that filesystem through time. All of that is assuming a world where our dagger container engine supports bind mounts at all, which is currently does not.

What we can add fairly easily, though, is the ability to bring other non-repo host directories into the env container -- like you should be able to configure an env to include the host's /opt/tooling at some path inside the container

[luketych]

@cwlbraa Sorry, I’m unfamiliar with the inner workings of dagger container-use — I was just sort of pseudocoding the idea.

What you said makes sense, especially if it aligns with how Dagger is designed to manage layered filesystems. So as far as I understand, edits are meant to happen from outside the container via Dagger’s API, and not from within.

Does that mean we should use something like container.withMountedDirectory(...) to bring in additional host directories (like a prompts/config folder or shared dataset) into the container environment? And if so, is there a recommended way to handle multiple mounts in that model — for example, mounting both the project root and a shared ~/llm/prompts folder?

Thanks for clarifying — just trying to figure out the cleanest way to support LLM workflows across multiple projects.