container-use

[jovial nimbus]

Discussion on hacker news: https://news.ycombinator.com/item?id=44193933

aluzzardi

Show HN: Container Use for Agents

Hacker News · Jun 5, 2025, 5:44 PM

[prime mason]

This is fantastic. I just added it to kilo-code - here is a video of the creating two environments for 'hello world' using flask and fastapi video

[frank sundial]

Thanks for sharing this! We'd love to highlight this more. I'll DM you 🙂

[opaque zephyr]

@prime mason thank you! we should add kilo-code integration instructions in the readme 🙂 want to open a pr? 🙏

[opaque zephyr]

https://x.com/asheshdhakal0/status/1930709309425406050?s=46

Ashesh Dhakal (@asheshdhakal0)

@_catwu As much as i love claude code, please bring an easy way to reverse to a checkpoint, the only way i know is through prompt and i always fear it forgets or cant reverse the code exactly as it was

X · Jun 5, 2025, 7:32 PM

[flat oar]

This is really interesting https://github.com/humanlayer/12-factor-agents

[prime mason]

Happy to do it. This will be my very first PR !

[prime mason]

PR opened

[opaque zephyr]

FYI https://github.com/dagger/container-use/pull/23

[jovial nimbus]

https://x.com/bradwmorris/status/1931030786213605664
“multi-agent madness”, great name for a future demo video

BradWMorris (@bradwmorris)

if you have < 1 hr to catchup on @aiDotEngineer -

1. @simonw 's pelican generation benchmark,

2. @solomonstre live demoing and open-sourcing multi-agent madness

https://t.co/2OhbFlhiGR

X · Jun 6, 2025, 4:49 PM

[opaque zephyr]

We passed 500 stars on github 🙂

[smoky mortar]

https://news.ycombinator.com/item?id=44226978 <-- container on mac native... Seems like low hanging fruit for dagger?

thm

Apple Announces Foundation Models and Containerization frameworks, etc.

Hacker News · Jun 9, 2025, 5:44 PM

[opaque zephyr]

Yes this will remove friction to installing CU on Mac, it comes at a perfect time for us

[smoky mortar]

Please Let me know if you have a few moments to chat any time this week.

[opaque zephyr]

FYI @cosmic birch @restive pumice I filed an issue to track (one of ) friday's topic. IMO it's an important one. https://github.com/dagger/container-use/issues/45

[opaque zephyr]

IMO this requires moving away from "each env is a branch" and towards "each env is a fork". At the moment our architecture straddles both concepts.

Constraining each env to a single branch IMO is incompatible with letting the agent work freely. What if the agent wants to juggle 5 branches for whatever reason? There's just no way to square that circle IMO.

Now, if each env is a fork, that feels more robust. First it maps better to the COW mechanics of Dagger, and containers in general. A fork is basically a copy of a directory. We can work with that.

Now, if each env is a fork - don't we lose the convenience of having a ready-to-merge branch from each env? Well yes, but I was thinking - git already has a system for that and it's called a remote. What if instead of showing each env as a branch, we showed each env as a remote? Then we can use git's existing tooling and conventions for finding and using the branches from each remote

One downside consequence of this would be, that we wouldn't have to use git worktrees. Instead we would use more vanilla git features. Basically remotes, and moving objects and refs between them

[opaque zephyr]

also as discussed I think we should group all the state into a unified custom ref instead of splitting the workdir and the rest. workdir should not be a special case in the state

[restive pumice]

I agree with the general vibes regarding robustness, but i'm be a little concerned about whether standard git UXes do a good job handling a local repo with a bajillion remotes. I also don't think that the original problem irt agents being unable to use git in containers necessarily needs to be coupled to enabling agents to use multiple branches in containers... this is plausibly something that we can increment towards.

Now, if each env is a fork - don't we lose the convenience of having a ready-to-merge branch from each env? Well yes,

lol i'd answer your rhetorical question with "no" , but it does get immediately weird because of restrictions on tracking branches. say i wanna create an env, starting from my local checkout of main. ok, make a new remote, call it env-adverb-animal, push main to to env-adverb-animal, mount it in a container, agent commits changes... now we've got new content on env-adverb-animal/main, BUT there's no good way to "link" that up to my source repo main because that main is supposed to track origin and you can't have 1 branch tracking 2 remotes

[opaque zephyr]

but there are standard git commands to manage all that and we can automate them if needed

more importantly it all maps to a familiar workflow for the user

[restive pumice]

i'm mostly concerned about fetching fwiw, or "refresh" buttons in guis

but you're probably right that it can be automated by server for the most part

[hexed warren]

(FWIW: we can prefix remote names with cu/ so that an env remote is cu/$ENV_NAME)

[restive pumice]

anyways the "you only get 1" restriction on tracking branches is the bigger concern here, like i still think we need source-repo checkouts of agent-created work, and if we want to show the user that the agent is continuing to work on a given branch, I don't see how we can get away from envs creating a branch, or eventually multiple.

but maybe the layout is something like cu/{$envRemote}/{$envBranch} where $envRemote is adverb-animal and $envBranch has a human-readable, non-collision-resistant name

actually wait no, that doesn't work... the branch name needs to be collision resistant if you wanna have a source repo branch that tracks it. otherwise you kick off the same task in parallel in 5 envs, and 4 of them fail because you're trying to create the same $envBranch source repo tracking branch 5 times with different remotes but the same branch name

[restive pumice]

so in short eschewing ties to branches basically throws away the possibility of populating tracking branches on the source repo. without tracking branches, git checkout envRemote/branch is always a detached head. that means you can merge it and log it without touching it, but the experience around checkout is gonna be weird:

more importantly it all maps to a familiar workflow for the user

people rarely use remotes without tracking branches in my experience, so having a remote without its own branches is unfamiliar, like in an uncanny valley way. concretely:

you'll have this detached head remote branch with a name that's very likely to collide with your local branch names or branch names from other remotes, and no automatic way to differentiate between what you've got checked out and the additional commits the agent has made since then.

all that said, you could of course have an env have both its own remote and it's own branches, each designed to be collision resistant. that said, i think the UX there is quite bad, it's a lot of random identifiers thrown in the users' face, and i'm not sure what concrete additional functionality we'd gain from adding the additional layer of identifiers for the remote when each branch is already unique, tracking, and so on

i'm also skeptical that users want an agent making changes to multiple branches... part of the value here has to be an opinion about how and where to contain an agent. reading from other branches has some obvious marginal value like "adapt this PR branch to additionally do XYZ", but idk when you'd really need an agent to have 1 environment with 2 different writable branches- why not fork the environment or even create a fresh one?

another random thing: we could totally make the envs look more like remotes if we want... tibor pointed out that that we can prefix remote names with cu/ to get cu/$ENV_NAME/human-readable-branchname... we can also switch the order of the branch identifier and change the remote name to cu/ to get a remote ref cu/$BRANCH_NAME that looks like cu/adverb-animal/human-readable-branchname

which tbh maybe helps with the cognitive overhead of what's going on here... i was optimizing for useful tab-completion where you type cu/flask-app/<tab> and see a list of environments that have been created to write a flask app, but maybe it'd be better to promote the illusion that only human-readable-branchname is actually a branch? ... downside to that is that you'd still not be able to git checkout human-readable-branchname because the tracking branch would still have to be adverb-animal/human-readable-branchname for the collision resistance

sorry for the novel lmao, imma log out

[restive pumice]

speaking of random git features that may have weird UX if we use them for novel purposes: the UX around pushing tags is HORRIBLE -- when i was trying to get rehydrate working i briefly experimented with tagging the initial commit of each env, and now i keep accidentally pushing those tags upstream. git push --tags --force origin v0.0.0 somehow pushed a tag for me just now that wasn't v0.0.0

[potent canopy]

I'm still digging the git implementation to gain an intuitive understanding -- I have to say, Connor, that the current state is very clever -- a lot of nice tricks 🧠

[restive pumice]

lol shit, i was trying to make it dumb but it came out clever instead

[jovial nimbus]

post and discussion about containerized dev environments for coding agents. i suspect folks in this channel have something to contribute: https://news.ycombinator.com/item?id=44221655

bumbledraven

How I Program with Agents

Hacker News · Jun 9, 2025, 5:30 AM

[jovial nimbus]

https://lucumr.pocoo.org/2025/6/12/agentic-coding/
mentions container-use

Discussion: https://news.ycombinator.com/item?id=44255608

rednafi

Agentic Coding Recommendations

Hacker News · Jun 12, 2025, 9:22 AM

[hexed lance]

Heyho. Was pointed here from the hackernews thread on my post 🙂

I don't have a ton of feedback at the moment but i'm evaluating it

[opaque zephyr]

welcome @hexed lance 🙂

[jovial nimbus]

hey @hexed lance love the series, nice to see it's getting attention on HN. i'm using posts like yours to understand what people are trying to work with coding agents, and how that's going. so looking forward to hearing more about your workflow either here or in the next post.

[restive pumice]

welcome! i love how small world oss work is sometimes, we've had agents "build" roughly a billion flask demo apps while iterating on container-use for the last month 🙂

[cosmic birch]

welcome @hexed lance!

[sweet steeple]

Hi all, I'm trying to get cu working (from cursor), mcp server is up and running, got a fresh local and remote git repo; but i'm keep getting this git related issue:

failed to open environment: failed initializing worktree: git command failed (exit code 128).... not a git repository

I can log a github issue, but wanted to see if the experts here encountered smtg similar?

[regal veldt]

another 'small world' situation - you contributed the Twig template engine to my Chyrp PHP blog engine project waaaaay back in 2008 😄 welcome, funny to cross paths again!

[hexed lance]

Yes indeed! Small world 🙂

Hope you're doing great! Still think of that thing every once in a while since it sometimes shows up in the PHP world still

[regal veldt]

likewise! yeah, Twig really took on a life of its own lol

[cosmic birch]

Hi @sweet steeple! I'm going to try the same with Cursor, will report back in a minute

[restive pumice]

usually this means when calling environment_create the agent is providing a source argument that's not a git repository

[sweet steeple]

It mentions ‘.’ As source

[restive pumice]

gonna look into it, i wonder if cursor's like zed and it's running mcp servers with cwd=/

(i can't get cu working in zed because of this, it basically repeatedly fails to guess your project directory)

oh you know one way to debug, give it a complete path to the project in the prompt

[cosmic birch]

I just tried and it seems to be working ...

[cosmic birch]

Oh right, maybe!

@sweet steeple I started cursor from the git repository though (cd <repository>, cursor .) ... maybe that's why

let me try to start it from the macos dock directly see how it goes

[sweet steeple]

Can you collapse one of those tool calls? Just to check the source

Will try the cmdline start as well

[restive pumice]

@sweet steeple the other thing is we are assuming that you're working on a git repo here, that error would also happen if you haven't done a git init in your project directory disregard me, i can't read, you already said you've got a fresh local repo

[cosmic birch]

Could you try from the terminal, within the repo, to do a cu list? Just to remove Cursor from the equation and to check if cu is having issues with the repo itself

[sweet steeple]

Cu list works perfectly

git -log working in that dir as well

Tried commandline startup of cursor in the repo no success

Doing this by explicitly mentioning the repo dir at startup, still not working

Fyi, managed to get it working by explicitly adding a rule to point to the correct source directory

We can maybe add this to the cursor rule template?

[cosmic birch]

I tried the opposite (starting Cursor from the dock, opening the repository) and it also works, weirdly enough

[sweet steeple]

I’m on mac

[cosmic birch]

I'm on mac too

[silver abyss]

PR up for Amazon Q Developer CLI chat 🙏
https://github.com/dagger/container-use/pull/61

https://github.com/dagger/container-use/blob/2293be7103aaed2f18a6cb5aa010e4791ae5c90d/README.md

[potent canopy]

First big draft on the test suite: https://github.com/dagger/container-use/pull/65. The aim was to have:

1. a nice UX to represent the test cases
2. Focus on what I find critical to test -- a nice foundation
3. Found a few bugs -- but preferred to skip the tests and fix them in follow-up instead of mixing things

[jovial nimbus]

Does cu have caching? https://x.com/cablelounger/status/1923829160373301411
if so, it’s a benefit worth calling out

Andy Gayton (@cablelounger)

.@OpenAI 's cloud codex will need environment caching.

For the `xs` rust project, it takes ~8 minutes to fetch cargo dependencies and run a cold `cargo test`, which makes spinning up many environments for small tasks prohibitive

X · May 17, 2025, 7:53 PM

[opaque zephyr]

yes via Dagger. We could leverage it more, but we do have it.

[jovial nimbus]

@cosmic birch could you say more about that? token usage is a concern for some when running agents in parallel and in background. (except if they're if they're using claude code with monthly subscription.)

[hexed lance]

My plan is to play with container-use over the weekend, but I wonder what the strategy would be for services that I need. Eg: i have a database (postgres) and a cache (redis) that is needed during development. What would be the recommended way to split this up?

[cosmic birch]

Would you expect each environment to get their own isolated db/redis or for them to share something with the host?

I'll give it a try later today and report back on a recommendation. We don't have a good solution for that yet -- there is functionality in the run tool to launch background tasks and do container-to-container and host-to-container networking, but that's mostly meant for stateless processes (e.g. your app, not a db)

But maybe I can throw something very experimental together before the weekend 🙂

[hexed lance]

For the tests I’m working with rollbacks anyways so just having the db there works. For redis I could assign a prefix if the container gives me some seed I can use maybe. It’s all different options

The easiest option is to spawn more containers 😉

[cosmic birch]

Yep, it's the easiest. The only concerning part is ... you get an empty db/redis then what? Would probably need to prompt it into running migrations or something

[hexed lance]

My tests run migrations once so that’s okay

That said, migrating in parallel can cause issues

Since the schema is shared between workers then

[cosmic birch]

Yep. I was thinking of giving each environment their own instance of services (so even more containers)

[cosmic birch]

Yes, we have caching (dagger's caching out of the box). We didn't do a ton of optimizations so we're barely using it, but in the scenario you shared, "fetch cargo dependencies" would only happen once

That being said, AFAIK that's not going to save tokens, just time. Waiting for an MCP to finish doesn't eat up tokens, just (your) compute (@restive pumice right?)

@jovial nimbus e.g. it's something we got for free by building on top of dagger

[jovial nimbus]

Understood. And if they’re running in background while I’m getting coffee then it doesn’t matter if it takes two seconds or two minutes.

[opaque zephyr]

the time saved on initial setup can make a big difference

especially for more complex environments.

it also translates to compute savings

[cosmic birch]

@jovial nimbus Yep, what matters is tokens in/out. But when a command is cached, we still retrieve the output from cache (because the LLM might need it, e.g. "install foo" might return "ok I installed foo v1.2" which the agent actually needs)

[cosmic birch]

But yeah -- in this scenario, for the xs project, it would take 8 minutes the first time, a couple of seconds thereafter

Also it makes sense when you have multiple environments -- the first one will take 8 minutes, the next 50 environments will only take a few seconds

[cosmic birch]

might translate into a "sip of coffee" rather than making and drinking an entire one 🙂

[jovial nimbus]

Gotcha. So it’s a time saving benefit plus reassurance: if I spin up 10 agents right before I leave for coffee, I only need to wait a few mins to see and be assured that they’re off and running successfully and didn’t trip on some install failure

Oh and if I don’t like what the agent is doing I can terminate it and start over but this time not wait

There’s no cleanup and also no penalty for scrapping work and restarting.

[restive pumice]

the waiting doesn't consume tokens, but the output of the toolcall can... idk how that works out with caching but if cache hits re-return stdout from "fetch cargo depenencies" that can be a problem for token usage

[restive pumice]

the time savings here is a UX thing even in the async scenario: if it's gonna go off the rails, i do spend the first 45s looking at output before i run off for my proverbial coffee lol, so cache hits mean that that 45s is plausibly the agent starting to do actual work

it's like designing your long-running jobs for fast-fail - often a small change, but one that can be surprisingly valuable

[silver abyss]

My little cleanup friend for now when I've partied too hard

cu list | xargs -n 1 -I {} sh -c 'cu delete {}; git branch -D {};' && rm -rf .container-use && git remote remove container-use

[cosmic birch]

@hexed lance I added some very crude service management, each environment gets their own instance with network routing (e.g. in each environment "postgres" and "redis" resolves to their own instance of those services) + port mapping with the host for debugging

[hexed lance]

Are there services have an env var or how would I find them?

[cosmic birch]

@hexed lance when the agent enters an environment, it gets told which services are available and their addresses

right now you can either configure services manually or the agent can add them using an MCP tool (still debating whether it's a good thing or not to let the agent adding services)

There currently is no env var that gets set up automatically. However, <service name> resolves through DNS so you can have a static configuration to reach them out

[cosmic birch]

these 127.0.0.1:<random port> are to reach them from your laptop, however internally they're just reachable through postgres:<default postgres port>

[cosmic birch]

this is the response the agent is making for humans (with addresses reachable from the laptop), however it knows to use the internal endpoint from within, e.g. it generated this:

# Redis configuration
redis_client = redis.Redis(host='redis', port=6379, decode_responses=True)

[silver abyss]

https://github.com/danilo-leal/zed-container-use-mcp

[silent mason]

I feel like I must be missing something completely obvious given there are no reported issues around this in GitHub... but I cannot for the life of me get container-use to work. I keep getting connection refused when following the instructions in the README.

[DEBUG] MCP server "container-use": Connection failed: McpError: MCP error -32000: Connection closed
[DEBUG] MCP server "container-use": Error message: MCP error -32000: Connection closed
[DEBUG] MCP server "container-use": Error stack: McpError: MCP error -32000: Connection closed

I have Docker running, tried installing container-use both from the script and from source... no sym links + I am passing the full path. Intel MacBook if that matters.

Trying to run it with Claude Code.

[cosmic birch]

Hey @silent mason! What command did you use to add the MCP server to Claude?

Was it claude mcp add container-use -- cu stdio?

Sorry I need to head out for dinner, but I'll check in

[silent mason]

That worked, thanks!! I don't have the bash history to see what I was doing differently. Full path seems to work too claude mcp add container-use -- $(which cu) stdio. Glad it's PEBKAC and not actually a problem with my environment.

[cosmic birch]

I suspect maybe it clashed with another cu binary (there’s one in macOS) and gave that cryptic error …

[cosmic birch]

It’s in v0.0.2

[pliant merlin]

I'm running into the same problem as above. Claude Code on Mac M1.

Connection failed: McpError: MCP error -32000: Connection closed

My config seems correct though:

$ claude mcp list
container-use: /Users/amueller/.local/bin/cu stdio

I realise this is experimental so I'm totally happy if it's not fixable, but I thought I'd check!

for completeness, my version:

$ /Users/amueller/.local/bin/cu version
cu version 0.0.2
commit: 279639ade9a6f8fc376e2060659f68c04acb632e
built: 2025-06-14T01:29:33Z

[unkempt canopy]

~~apologies if someone already posted this type of error but I can't get passed this issue. cu mcp is up . cline 3.17.8-313 vscode 1.101.0 claude 3.7 sonnet : Git cloned a simple flask app and asked to create a simple flask app. Error on environment_open. Source is correct path to the cloned repo locally ~~Error: failed to open environment: failed intializing worktree: git command failed (exit code 1): exit status 1 Output: Could not get home directory: $HOME is not defined
$HOME env is set properly. opened vscode from terminal (mac osx) and directly and same error either way
anyone else hit this ?

I resolved this error by ensuring HOME was set as env in the mcp server config

[unkempt canopy]

I resolved a similar issue by adding the "/Users/XYZ/.local/bin/" to beginning of $PATH

[still robin]

https://github.com/dagger/container-use/issues/18

cc @opaque zephyr

[still robin]

https://simonwillison.net/2025/Jun/14/multi-agent-research-system/

^interesting read around the concept of multi-agentic systems

IMO quite relevant for the container-use use-case

[celest arrow]

I’m trying to use goose with container-use, but whenever I add container-use as an extension (just copying the template from the readme), goose hangs. Has anyone else ran into that?

[potent canopy]

Hey, can you please share your goose config 🙏 👀 -- Seems to be working for me rn

[celest arrow]

I’m trying to use goose with container

[left turret]

I think I got my repo into a weird state where I can't make new cu workspaces? Getting this error

> this app is faking the iss load because of CORS issues. Figure out how to make this work for real 
  pls. I am open to a light backend if necessary

● I'll analyze your ISS app and figure out how to fix the CORS issues to get real ISS data. Let me first examine the current codebase to understand what you have.

● container-use:environment_open (MCP)(source: "/home/evan/dev/iss_demo_take_two", name: "iss-demo-cors-fix", explanation: "Opening environment to analyze ISS demo app and fix CORS
                                      issues")
  ⎿  Error: failed to open environment: failed to propagate to worktree: failed to commit worktree changes: git command failed (exit code 1): exit status 1
     Output: On branch iss-demo-cors-fix/deep-sculpin
     nothing to commit, working tree clean

My git status looks like

iss_demo_take_two> $ git status
On branch main
nothing to commit, working tree clean                                       

Anything I can do to get out of this situation?

[left turret]

I also noticed that claude code will try using the container-use MCP like 3 times and then it will just start yoloing changes to my local environemnt (rm -f, git checkout ..., etc lol).

May want to update the base CLAUDE.md to tell it to give up on the assigned task if it cannot use cu

[opaque zephyr]

@hexed lance how did the week-end experiment go? 🙂

[hexed lance]

well it turns out i did an all-nighter with friends vibe coding

unfortunately i did not manage to use container-use 😦

[cosmic birch]

didn't get a chance, or tried and hit a problem?

[hexed lance]

just the type of problem did not lend itself to containerization well (xcode project)

[opaque zephyr]

@restive pumice any luck on getting this to work with Zed?

[restive pumice]

boutta give it a try again on the nightly

[potent canopy]

After fixing the issues found with the tests -- wdyt about: https://github.com/dagger/container-use/issues/81 cc @cosmic birch

[potent canopy]

Interesting, would you mind firing a PR ? or an issue with a repro 🙏

[restive pumice]

turns out the fix isn't on zed's public preview until wednesday, gonna try building from source but not gonna spend too much time yak shaving rust toolchains if it doesn't just work out the box

[silver abyss]

ran into a cu terminal error

[hexed warren]

https://github.com/dagger/container-use/pull/78 should fix it

[hexed warren]

@silver abyss if you wanna try the fix, i'd appreciate it. You can check out my branch and run go build -o ~/.local/bin/cu ./cmd/cu it will overwrite your installed binary (if you're not using homebrew).

[silver abyss]

I can! But I'm on homebrew, so can uninstall first

/opt/homebrew/bin/cu
brew uninstall container-use

[hexed warren]

probably safer indeed.

[opaque zephyr]

That's a very interesting edge case... In theory you could still benefit from the sandboxed file edits (via separate git worktrees) even if your build commands can't run in a linux container. Like a more streamlined version of the various git worktree hacks out there. Perhaps not worth the overhead?

cc @cosmic birch

[silver abyss]

@crimson plume and I got container use working on the experimental OpenAI Codex Rust CLI codex-rs that supports connecting to MCP servers 🎉
Documented here: https://github.com/dagger/container-use/blob/main/README.md#openai-codex

[restive pumice]

need a quick review for the homebrew tap automation

[hexed warren]

feel free to merge

[restive pumice]

tq, i gotta merge it and cut a fairly meaningless release to make reality match README

[hexed warren]

in the meantime you can merge my PR before making the release 😄

[restive pumice]

sorry for the inane questions about the POSIX details btw, i just want it written down

@hexed warren the one weird thing about your PS1 PR is that we might actually wanna have dagger in the terminal PS1 since we're powered by dagger (as opposed to container-use or cu)

but imma merge anyways

[hexed warren]

happy to change that

it was a suggestion

Also, i'm doing bash --version to show we're in bash, but happy to change the PS1 to include the name of the shell

[restive pumice]

i'm also fairly ambivalent about it, it's really a tech marketing question for @opaque zephyr @cosmic birch

explicitly: should the shell PS1 say container-use or dagger

[blissful mural]

Im trying to use just the built-in vscode/copilot features to use container-use, I set up the system as described in the README and I can see the container-use MCP, however whenI try to run the example it keeps trying to do things locally on my machine.

Anyone have a simple example using just copilot in vscode?

[cosmic birch]

/cc @potent canopy -- sounds like the instructions are not going through

[cosmic birch]

try asking "... in an environment". Should be the default when adding instructions to the project

@restive pumice @potent canopy @hexed warren Just did this on top of #62 (didn't want to get #62 too huge): https://github.com/dagger/container-use/pull/85

Basically just getting rid of the state history / revisions etc. That made sense pre-git but not so much now?

It does handle migration under the hood

[restive pumice]

need another quick release infra review: https://github.com/dagger/container-use/pull/86. the homebrew tap publishing worked, but the order was all weird in a way that doesn't match the instructions i commiteed to REALEASING.md and creates a lil window during the release where the brew tap will break

[hexed warren]

merged

[restive pumice]

grrrrr sorry 1 more attempt, i'm playing the push-and-pray game with goreleaser yaml here, but i'm like 90% i solved it properly this time. https://github.com/dagger/container-use/pull/87 @hexed warren

[restive pumice]

i do have a setup for testing this on forks, but the PAT setup is annoying

[hexed warren]

"Please try again" 🙂

[restive pumice]

woooo that did it

it does make the PR as me and the DCO is broken, but good enough for now

cool, we're all good and working on v0.0.5 and brew install dagger/tap/container-use. fyi @silver abyss since you installed from my tap as a test, you need to do this weird dance of brew uninstall container-use && brew untap cwlbraa/tap && brew install dagger/tap/container-use

[silver abyss]

just noticed
https://github.com/dagger/container-use/blob/main/install.sh#L66-L67

   log_error "Windows is not supported"
   log_info "container-use uses Unix syscalls and requires Linux or macOS"

but I can install on WSL and the cu binary runs...but it seems that cu stdio just returns after a second or so with no error message. Is there a way to debug this? Expected? edit: I used strace in WSL. See thread.

cc @restive pumice

Context: I was putting this in MSFT Visual Studio 2022 (not VS Code) and it seems like it will work fine with GH Copilot Agent except for this returning unexpectedly issue.

[weary rapids]

Hi, what if I want to do some experiments with container-use and I am not yet using actively any agentic coding tool? Which one requires no paid plan, or allows a very low rate for "hello-world"-like experiments?

[silver abyss]

just noticed

[potent canopy]

Hey 👋 , some people here have been using goose with google's gemini -- you have some quotas ; I guess VSCode with the integrated models is fine too

[indigo raven]

out of curiosity, has anyone been able to run goose + container use as a headless auto scaled multi user service?

Goose as a multi-user, pod-per-user service:
1. Auth: best OIDC/OAuth layer to map incoming users to pods.
2. Orchestration: operator/spawner that spins up (and reuses) one pod per user/session.
3. Storage: per-user persistent volume (EBS/EFS/S3-fuse) auto-attached so Goose retains history.

My main issue right now is mapping an auth identity to their own sessions / workspace, since goose in its current state, assumes that it’s a single user

perhaps the answer is just a separate goose Kubernetes deployment for each user, when the tech is still young

[silver abyss]

woah! Sounds cool. I haven't heard of anyone pulling that off yet, but I'm super interested! 🍿

[flat oar]

Kind of rough, should be able to push something up later today, but started a wip VS Code extension to setup commands and register the MCP server for container use...

[crimson plume]

does it actually open the environment in the editor? or just configures the container-use mcp?

[flat oar]

Registers the mcp server and adds commands, but I’m not sure those are worth while? Maybe a command to setup like the proposed doctor command?

[crimson plume]

yeah if it just configures the mcp server i was wondering what the use case is for installing an extension instead of just dropping in the json config

[restive pumice]

i think it's mostly that extensions can be a nice release channel - you can update container-use when you update your other extensions and some users don't ever wanna interact with a CLI (regardless of whether that's cu, brew, or apt-get)

[crimson plume]

ah so the extension actually distributes the binary too?

[restive pumice]

yeah one day (prolly not in jason's first go, though)

[flat oar]

Probably helps with discovery being on the marketplace?

[crimson plume]

yeah i was wondering about that for cline too - they have an mcp-marketplace although it didn't seem like its actually getting updated unforunately

https://github.com/cline/mcp-marketplace

i'll make an issue there anyway

[restive pumice]

sometimes when i find random packages like this i wanna use in my dev setup, if i'm kinda ambivalent about the idea like it's not a strong "need", i look at a github readme and they want me to build from source or even download the binary manually from the releases page, i will check to see if somebody else has put it in homebrew or the aur, and if they haven't i do not download - extensions solve this

[flat oar]

Actually, I can probably look at how the go extension install gopls and other tools and follow suit with a prompt if we can’t detect cu?

[hexed warren]

@restive pumice https://github.com/dagger/container-use/issues/66#issuecomment-2981770619

[blissful mural]

@silver abyss any luck with getting this to be less overwheliming of a command? 🙂

q chat --trust-tools=container_use___environment_checkpoint,container_use___environment_file_delete,container_use___environment_file_list,container_use___environment_file_read,container_use___environment_file_write,container_use___environment_open,container_use___environment_run_cmd,container_use___environment_update

[blissful mural]

Or even a way to save this by default?

[hexed warren]

Looks like it's only with the non-brew version

[crimson plume]

i think you can put this in the config json

[blissful mural]

Help me im two weeks behind 😄

~/.aws/amazonq/mcp.json or somewhere else?

[crimson plume]

cline for example https://github.com/dagger/container-use?tab=readme-ov-file#cline
see the autoApprove field

yes in there

"autoApprove": [
        "environment_file_read",
        "environment_open",
        "environment_run_cmd",
        "environment_update",
        "environment_file_write",
        "environment_file_delete"
      ]

[blissful mural]

You are my hero, any reason not to just add this to the README?

[crimson plume]

yeah @silver abyss and I briefly talked about that yesterday. I'm not sure how opinionated people are about their auto-approve lists. My theory is that the concept of auto-approve is going to change very quickly. We could provide one block that has every tool listed in the autoApprove array though

i can add that in a sec

is there a way right now to see a diff of a merge before merging? i dont see anything in cu merge -h for flags

[blissful mural]

Amazon Q is working really well for me, thanks for the demo @silver abyss

[silver abyss]

If you run the big command, likely you’ll see the config file if it exists.

[silver abyss]

Yeah, I was pleasantly surprised! Works great in terminal too for suggestions

[blissful mural]

Oh I am only using in Terminal haha, is there some other way 😂

[crimson plume]

https://github.com/dagger/container-use/pull/93

[crimson plume]

its cu log <env>

[restive pumice]

hmmm.... we can add signing/notarizing to the release automation, i can prolly dig up some keys from dagger/dagger and justin, but this is still surprising to me that removing the signature helps because nowhere in the config do i do anything with signing

also adding signing is likely to break any ability we have to "test release" using forks, so there is a drawback there

[hexed warren]

Then the problem is there is no signature.

codesign -s - adds an ad-hoc signature

[restive pumice]

ah cool, makes sense

[hexed warren]

But that only works when the user does it, you cannot do that in the release scripts

[hexed warren]

Although, TECHNICALLY, we could do codesign -s - in the install script 😄 but that would make us look really bad

[silver abyss]

I’m a bit late to this discussion, but I did it the way I did with Q because it seemed the most idiomatic for now 😄

[blissful mural]

Im gonna make an alias for myself, but otherewise its all good

[silver abyss]

Half the battle was figuring out the format that each tool uses to refer to a particular MCP and it’s tools. Q was totally different than Claude code for example.

[cosmic birch]

@silver abyss@crimson plume Hey thank for you adding the integrations for all those agents!

I was thinking ... what if we had a cu configure (name TBD) that:

1. Detects which coding agent you're using (or asks you if we can't figure it out)
2. Configures MCP. Configures the rule. Configures the yolo-auto-approve

This would greatly simplify the installation process (e.g. avoid the issues @blissful mural and others run into), while keeping our getting started a one liner (e.g. we'd still provide the docs for each agent, but that's an "advanced" use case on a separate page)

[/cc @restive pumice @hexed warren @potent canopy]

If you think it's a good idea I'll file an issue.

I think this thing should work both in interactive mode and in unattended mode (e.g. cu configure --yes or getting confirmations for Yolo update [Y/n])

[cosmic birch]

The other thing ... the yolo updates, every time we change the MCP tools, those things are going to be outdated. We could have users just re-run cu configure to get the latest updates

[potent canopy]

Yeah, I hate those mcp docs -- I want a 1 click button

[crimson plume]

Yeah that sounds awesome especially if we can interactively choose the agent or multiple agents

[hexed warren]

We were talking about this at lunch 🙂

[cosmic birch]

Fun fact: me too 😄 different lunch, same topic

[potent canopy]

Btw, I fixed the host caching issue -- it's draft-y and burst the cache, and probably potentially fixed by your environment PR Andrea: https://github.com/dagger/container-use/pull/96 (I'll see after your rebase)

[potent canopy]

Might be worth merging with this cu doctor potentially, or maybe under the same namespace? https://github.com/dagger/container-use/issues/81.

I want, as a UX:

curl install_script.sh # command to install 
cu doctor # everything is green
cu configure claude # boom it works

[crisp summit]

How can i pass aws credentials to the environment created from computer-use?

[cosmic birch]

We actually have (undocumented) secrets support.

You can ask the agent to use secrets ("Use the AWS credentials found in <secret reference>")

<secret reference> works via secret providers, it currently supports:

• env://ENV_NAME <-- environment variable
• file://PATH <-- secret in a file
• op://<PATH> <-- 1Password
• vault://<PATH> <-- Vault

[crisp summit]

Do you pass the computer-use logs to your server?

[silver abyss]

do you mean "container-use" when you say "computer-use"? Just to be clear 🙂

[cosmic birch]

container-use runs locally (and is open source), there are no external servers involved

[crisp summit]

oh yes my bad. container-use

[silver abyss]

why not both? (I didn't realize that computers in tupperware containers was a thing 🤣 of course it is)

[opaque zephyr]

@cosmic birch you reminded me to file this issue https://github.com/dagger/container-use/issues/98 (for later)

[hexed warren]

I already filed an issue for it on D-day, you commented on it 🙂

https://github.com/dagger/container-use/issues/12

[opaque zephyr]

Slightly different, issue 12 is for having the feature. Issue 98 is specifically for hiding secret references from the model (ie. virtualize them)

[cosmic birch]

Yeah I was about to file a similar one after typing in here and you beat me to it

Fun fact: looks like this container-use PR was created using container-use: https://github.com/dagger/container-use/pull/80

Note to self: the commit messages are good to observe the agent, but not so good to share as a PR ... we should tweak that

/cc @opaque zephyr @restive pumice

[flat oar]

I was thinking something similar like a setup (naming?) command would be super helpful instead of copying files from the README. Something like cu setup vscode|claude that would add the mcp config and extras directly in the repo would be a really nice DX!

[flat oar]

Ok, got a lot farther with the VS Code Container Use extension:

1. Added a command to "setup" the environment. This adds the mcp.json and prompts the user to add the optional copilot instructions
2. Auto registers the MCP server when installed (which is why it showed up twice in the list )

TODO:

1. Check that the directory is a git directory
2. Look at how the Go extension installs gopls and do something similar for cu so the user only needs to install the extension
3. Prewarm the host machine (e.g. make sure Docker is there and pull the container image for the engine behind the scenes)

[still robin]

@cosmic birch regarding allowing container-use to potentially include third party stuff (files, directories) into the environment. Seems like once installed and configured, container-use has a high influence on what the agent does even if other MCP's are also registered in the agent session, doesn't it? cc @agile jacinth

[potent canopy]

Are we ready to merge your PRs #62 and #85 Andrea ? Just to ensure that this part of the API is stable and I can rebase the tests

[cosmic birch]

Yes, it's ready. Was waiting to get some more feedback from you, @restive pumice and @hexed warren. Ok to merge?

[restive pumice]

checking again for err handling, 1 sec

[cosmic birch]

@still robin Yes. Once the agent is tricked into using container-use once (because of the prompt), it gets an environment_id and is "stuck" to keep using it (e.g. no other MCP server takes an environment_id except container-use, so the agent has no choice)

[cosmic birch]

@potent canopy @restive pumice merged!

[potent canopy]

Yaay, thanks 🙏

[flat oar]

Is it possible to update the version command to also include the Dagger SDK version? I need that to pull images dynamically

[restive pumice]

func (env *Environment) buildBase(ctx context.Context) (*dagger.Container, error) {
    sourceDir, err := dag.
        Host().
        Directory(env.Worktree, dagger.HostDirectoryOpts{NoCache: true}). // bust cache for seperate calls (create vs update)
        Sync(ctx)                                                         // but when restoring from env.container, sourceDir changes shouldn't bust cache

@cosmic birch i think this gives correct caching behavior for the host dir load btw, but i think it also might introduce a durability requirement on the dagger engine cache. like if you lose your engine cache, then try to restore one of the saved environment.container LLBs, this directory ID is gonna be missing, i think?

it's an edge case kinda, but one super cool thing is i think we can catch that error, and if we've saved off the initial ref, we can almost certain rehydrate the ref into some other worktree, then call this sync again to refill the cache.

[restive pumice]

there is a problem there, though, in that we'd then have to do a step by step rewrite of all the container-use-state notes after that "create environment" commit cuz every one will have changed

[flat oar]

When you have a ton of environments, would it be helpful if there was a description based on the prompt you could view for each one?

[potent canopy]

Yes, totally

[cosmic birch]

Not sure I follow but it’s been a long week 😄

https://github.com/dagger/container-use/pull/105

^^^ I just opened this. The PR itself doesn’t matter much, the cool thing is I mostly built this using container-use and goose, lots of dogfooding! Will dump some raw notes

It’s good overall, but some UX quirks

I think the most annoying ones were:

1. switching between envs / resuming / etc: As @flat oar mentioned it would be useful to have a description or something, it’s very hard to find your environment back. But generally speaking, how you interact with an environment (create vs update) needs refining

2. Commits. Currently our commits are meant to “observe” what the agent did.However if you “use” them as regular commits, they’re not very good!

The description is not great, and the logical separation is not great either: we have one commit per file change, but as I was iterating each prompt was modifying 4 files and generated 4-5 commits … it’s almost impossible to rollback, cherry pick, etc. Also to open the PR I had to manually squash 100 commits into something logical

I don’t know how, but it would be better if the agent could split up the commits into logical working units, with a good description … and maybe having the low level changes as notes

3. small UX quirks

[flat oar]

I wonder if the environment has a sentence descripton summarizing your prompt if the environment name can be a simple petname?

[cosmic birch]

Yeah maybe a short/long description. cu list would list the short desc along with a timestamp? And cu info (?) the long description …

We’d keep the description updated throughout (offering a tool so the model can update the summary)

The new container-use-state can now have multiple fields aside from the container-id, this could be a good place to stash such info

[restive pumice]

lol sorry i was at the end of my brain rope as well, just had to write it down somewhere

[formal ledge]

Trying to wrap my head around how this things work and couldn't figure it out from reading the docs. I'd love to use this for my elixir/phoenix apps, is that possible? How does it know what kind of container to spin up?

[formal ledge]

Never mind I see. It looks like it tries to create a container on the fly and pick which base image based on your project.

[sharp otter]

is this expected behavior for now or a gap to be fixed ? the end summary instructs checkout but the changes are not in the checked out branch unless doing a cu merge ? If this behavior is expected, then the end summary should be corrected by tuning the copilot instructions https://github.com/dagger/container-use/blob/main/rules/agent.md ?

[restive pumice]

we're definitely abreast of this UX paper cut and several others around it- a ton of dagger employees have had similar problems. the hard part is that you can get the up-to-date checkout with git checkout container-use/<branch-name>, but that's a detached head because of how remotes work and lots of ppl are disoriented with a checkout of a detached head. we're actively iterating towards something that will be less confusing, so when you initially check out the agent's work it'll be up-to-date.

we've tried a bunch of different ways of prompt engineering around this, all of them work sometimes, but hopefully by changing the git integration slightly, we can get something that works all the time

[sharp otter]

I've been using cu lately and it already works for one of my use case so far, which seems very promising . Just spotted a bug during my test and opened a https://github.com/dagger/container-use/pull/112, could anyone take a look ?

[violet pebble]

this might be more of a general dagger CLI question but I got to it using container-use the LLM spun up a node server http://127.0.0.1:55659 and it's still accessible but when I look at docker ps only dagger engine is listed, and I'm wondering how can I see the actual container still running

[restive pumice]

a lot of folks have been saying that container-use is "powered by docker containers" .... the reality is that it's powered by dagger containers, and because they're highly ephemeral and there a bajillion of them, there's no dagger ps command

tbh dagger should probably have a dagger services command, because those are sometimes not so ephemeral, like in raw dagger you can do dagger call fn-returning-service up and it'll stick around for as long as that cli process is running, but until container-use, that workflow is mostly used with terminal splits

[restive pumice]

looks good from 100 feet, will try to repro and merge tomorrow

[violet pebble]

Ahh OK yeah for this use case I am looking for something closer to a dagger ps because I don't get how to interact with the container the agent spun up

[restive pumice]

ahhhh there's cli commands, you're looking for cu list

[violet pebble]

Ohh awesome thanks!

[restive pumice]

also cu terminal, cu log, etc

[formal ledge]

I’m finding my background command I’m running (a phoenix server) is constantly dying after a short bit of time. Any thoughts as to why that’s happening?

[hexed lance]

so some feedback on container-use so far: it definitely works, i don't entirely enjoy it yet. I think it needs to get much easier to understand wtf is going on as the agents are working and how to see it

the killer feature for sure should be actual parallelism but i find that just to be too hard to use right now

[blissful mural]

I had cu working great with claude but all of a sudden I seem stuck in a loop where no matter what I try its no longer able to do git operations.

Seeing things like this fatal: not a git repository: /home/levlaz/.config/container-use/repos/slopshop/worktrees/becoming-falcon

It does all the right stuff but then when I try to cu merge or git checkout none of the files are saved or changed in the worktree.

trace: https://dagger.cloud/levlaz/traces/7efdad517ef682dc576b21790295bd5d#a649a4ac25ec0228:EL1

Any ideas?

[restive pumice]

that is definitely a bug, the repo path should be /home/levlaz/.config/container-use/repos/slopshop

[frosty locust]

Not sure if it's possible but with brew install if you could have it warn when cu utility already installed like the script does it would be useful. Cost me a few minutes repeating same troubleshooting step after setting up on a new system realizing it was due to the same binary name conflict.

[restive pumice]

I’d love to know more, was this Linux brew? On macOS there’s always another cu binary, but the homebrew PATH will also always precede /usr/bin. the intent of the tap was to have it “just work” but there are edge cases we could warn about

[opaque zephyr]

Thanks for the feedback, it's very appreciated.

Yes we agree and solving the "wth is going on" issue is our top priority.

[valid siren]

Does container-use support using Podman instead of Docker ?

[opaque zephyr]

yes, see https://docs.dagger.io/ci/integrations/podman/

[still robin]

here's my cursor Auto-run config so you don't get annoying tool prompts each time the agent uses container use .

The here's the list of commands:

mcp__container-use__environment_checkpoint,mcp__container-use__environment_file_delete,mcp__container-use__environment_file_list,mcp__container-use__environment_file_read,mcp__container-use__environment_file_write,mcp__container-use__environment_open,mcp__container-use__environment_run_cmd,mcp__container-use__environment_update

[blissful mural]

In case it helps anyone, I have this useful one liner that I add into my justfile (or makefile) that lets me clean up everything that is happening at the moment. I am not sure if its actually a good thing to do this but does seem to help when I get stuck in a weird spot.

clean:
    cu list | xargs -n1 cu delete
    git branch --list | grep -v main | xargs -r git branch -D

first bit cleans all cu environments, second bit removes all branches except for main

[cosmic birch]

Appreciate the feedback! And agree with the sentiment, currently doing a bunch of dogfooding to improve the tooling

Do you think it's a tooling problem (e.g. give me more tools to figure out what's going on) or the complexity of the architecture?

[crisp summit]

I m starting to see a weird issue while using CU with kilo. I have this configuration in the MCP_settings.json which would add the CU as MCP tool in KIlo. { "mcpServers": { "container-use": { "command": "/opt/homebrew/bin/cu", "args": [ "stdio" ], "env": {}, "alwaysAllow": [], "disabled": false } } }. However i keep getting MCP error -32000: Connection closed error from the server status . Has anyone else faced this. How can i debug this further?

If it helps, this is how it looks like

[blissful mural]

Is there some good pattern for avoiding git conflicts? For example ill open up a cu generated thing in my editor and edit it. Then start a new session in cu but it keeps trying to update the old file instead of branching off of the latest.

Same thing happens when I delete a file, it keeps bringing it back in.

Anyone run into this?

[restive pumice]

it keeps trying to update the old file instead of branching off of the latest.
like it's creating a new environment, but not getting your local untracked changes?

ill open up a cu generated thing in my editor
say more, is this after git checkout env-id; git pull? and then are you still on that branch when trying to create a new environment?

[restive pumice]

MCP error -32000: Connection closed error from the server status . Has anyone else faced this. How can i debug this further?

start a tail -f -b0 /tmp/cu.debug.stderr.log, then toggle the server off and on again in kilo. do any logs appear? what happens if you run /opt/homebrew/bin/cu stdio directly? (could be a binary signature issue, could be something else, tryna eliminate the signature issue)

[blissful mural]

Yeah, but then ill switch back to main and start a brand new session. It will make a new branch but feels like its branching off something other than my main branch

[restive pumice]

im confused, you switch back to main, but are you're expecting main to have edits from the env branch? or is it the other way around, you expect creating a new session on main not to have edits from the env branch?

[blissful mural]

Sorry for any confusion. This is switching back to main after merging everything. Then wanting to move on to a net new tasks.

I am expecting to start the net new task from wherever my current HEAD is I suppose. But that does not seem to always be happening.

[restive pumice]

ahh gotcha that makes way more sense. it should absolutely be starting the net new task from your current head

cu version?

(main is a mess right now btw)

[blissful mural]

Ha,

levlaz@nao:~/git/image-annotator$ cu version 
cu version 0.0.5
commit: e3aabe8daffbe3e12a1042e75848d41657183d98
built: 2025-06-16T23:26:03Z

am i living in the past?

[restive pumice]

you are not

that's the most recent stable

@blissful mural are you using cu merge to do that merge? and are you making the changes on the env branch and then committing them?

        cmd := exec.CommandContext(ctx, "git", "merge", "-m", "Merge environment "+env, "--", "container-use/"+env)

(cu merge merges the remote ref, not your local checkout, so any changes you added locally before merging are lost)

[blissful mural]

Yeah I am probably doing this wrong I feel like I am doing

cu merge

edit on main

commit from main. I basically never go to the branch that cu is creating locally.

Either way feels like we should document the correct workflow here because its a bit confusing. If you are 100% vibing it works great, but as soon as you try to be a human in the loop I am noticing it becomes a bit more challenging.

[restive pumice]

yeah we're working on it, right now there is no correct workflow.

but more importantly, if you're committing on main and then it's still not getting those changes when creating a new env, it's not a "you're holding it wrong" thing, it's a bug

i don't think it can be a cache problem, but maybe there's something about merging that messes up initial worktree setup?

[blissful mural]

Ill work on a repro and file a bug report! \

[hexed lance]

Not entirely sure. I think a lot of it is tooling for sure. But some of it is probably inherent

[silver abyss]

In case it helps anyone, I have this

[crimson plume]

https://tenor.com/view/arrested-development-jason-bateman-michael-bluth-do-not-open-dead-dove-gif-3567411

[abstract harness]

hi, version installed with homebrew (macOS) has missing commands, is that ok?

Like, no version command

[potent canopy]

thanks, taking a look 🙏

[restive pumice]

can you share your

brew info container-use
==> container-use: 0.0.5
https://github.com/dagger/container-use
Installed
/opt/homebrew/Caskroom/container-use/0.0.5 (14.1MB)
  Installed on 2025-06-16 at 16:33:36
From: https://github.com/dagger/homebrew-tap/blob/HEAD/Casks/container-use.rb
==> Name
None
==> Description
Containerized environments for coding agents
==> Artifacts
cu (Binary)

[abstract harness]

==> container-use: 0.0.5
https://github.com/dagger/container-use
Installed
/opt/homebrew/Caskroom/container-use/0.0.5 (14.1MB)
  Installed on 2025-06-19 at 23:25:40
From: https://github.com/dagger/homebrew-tap/blob/HEAD/Casks/container-use.rb
==> Name
None
==> Description
Containerized environments for coding agents
==> Artifacts
cu (Binary)```

[restive pumice]

how about which cu

[abstract harness]

/Users/myuser/.local/bin/cu

[restive pumice]

see that's not the version you installed with homebrew, that was installed with the install.sh script

[abstract harness]

oh, I see

[restive pumice]

rm -f /Users/myuser/.local/bin/cu and you'll get the newer brew one instead

[abstract harness]

nice, thanks... will do after this vibe coding session ends 🙂

[potent canopy]

i had some weird brew state making me unable to find container-use with brew ; everything is fine on our end indeed 🙏

[jovial nimbus]

So, who’ll be the first to try container use with Gemini CLI? https://github.com/google-gemini/gemini-cli
Very curious how it does with parallel work compared to Claude Code

[hexed warren]

@cosmic birch @restive pumice for the shell completions, it is indeed a mess. There are two kinds of people: those who know what they're doing and know the cu completion bash pattern. For the rest, I'm debating to add an install command that detects the shell and tries to smartly modify the right rc file depending on the shell and the system. (detect if completion already installed, and append if not installed). I don't mind owning it if issues come up. So the UX would be cu completion install and that's it

[hexed warren]

For the record, docker installer modifies the shellrc that's detected. Kubectl has many pages of docs just for completion based on shell and platform.

[restive pumice]

Lemme put my shell thing up as a PR, it takes a different approach

[cosmic birch]

I think if there's a way to add that to homebrew ... and then people installing manually we should give the the one off command (not persistent) and let them deal with it?

[hexed warren]

I hate homebrew so much I can't in good conscience recommend people to install homebrew for container-use, but if people already have it it is an easy install.

Which is why i'd like a "simple install + completion" that works for people who don't have homebrew. And that's a different target from "people who know what they're doing"

[regal veldt]

related topic: a cu init would be nice to skip the manual curl ... > CLAUDE.md step

[hexed warren]

I think there's a cu configure PR up

[regal veldt]

oh sweet

[potent canopy]

I'm splitting the test PR -- latest changes makes it a bit too big

[restive pumice]

i love brew so much i use it on non-arch linux distros sometimes lmao (the aur is better, hence never on arch based distros)

[crimson plume]

its always fascinated me how many linux users use homebrew

[potent canopy]

don't say that to Marcos ahahah -- he's converting everybody to his package manager

[restive pumice]

part of it is just that i understand how it works, i like ruby, and i used to move lists of packages between OSes a lot

[hexed warren]

I wanted to like it, and then it just actively betrayed me with things never working and autoupdating. Even the workaround to not autoupdate doesn't quite work.

[crimson plume]

but it doesnt have the concept of versioning, which imo makes it not a package manager

and thus continues the great debate 🤣

[restive pumice]

lol yeah the autoupdate thing is wack, at brex our IT dept had some daemon thing on everybody's computer that made it even more broken

and casks are versioned sometimes, when you can have them (which tbf isn't often)

[hexed warren]

Anyway, my point is we don't have to actively push people to use brew if they don't have it and container-use should still be simple to set up

[restive pumice]

💯

though i think it's fine to actively push macos users to use it, and they're (we're?) a specific breed with high usability expectations and relatively low tolerance for figuring shit out themselves

[crimson plume]

if the setup is a builtin subcommand, it can still be run as a post_install automatically in the formula

i think

[restive pumice]

https://github.com/dagger/container-use/pull/133 PR up. the main thing i'm trying to accomodate is that many users, myself included, don't want to put completion hooks in their rc files - there are autoload spots on disk

[hexed warren]

there are autoload spots... IF there are. But if there aren't we should set it up in the rcfile so that it does check those autoload spots.

[restive pumice]

yeah i've basically tried to leave it up to the user but give clear instructions on install.sh

because the fanout of conditions is kinda ridiculous if you're autoinstalling on an unknown machine, and like cu configure, we have no way to automated test any of this

[restive pumice]

wait, @potent canopy, is it too big just aesthetically or is it too big in that part of it is broken and can't get in until it's fixed? like i see passing tests on the PR, if it's only too big because it's hard to review or aesthetically upsetting, imo we should just pull the trigger and get it in before andrea and I make you 1 bajillion more merge conflicts

[potent canopy]

it's just big because a lot of files ahah -- everything passes

[restive pumice]

I think speed is the priority then, we can iterate on it after?

[potent canopy]

Yeah totally 🙏

i already have some fixes that cleanup some code duplication in the helpers -- i'm ok merging as is personally and open them as followups

[potent canopy]

Just wanna do anything to help you guys review and get it in -- so open to suggestions

[cosmic birch]

is it ready to be reviewed? sorry missed the last hour of messages, was out for lunch

[potent canopy]

I mean, as is yes -- I was planning on splitting it ; and i have some code dedup as a followup -- but Connor convinced me to ship it fast

[cosmic birch]

started reviewing, looks good so far!

[cosmic birch]

@potent canopy reviewed, left minor nits and a big question. However aside from one comment which changes the behavior, all the rest can be done after.

@restive pumice ?

[restive pumice]

lgtm too

[potent canopy]

do you guys want me to fix the comment that changes the behavior ?

[cosmic birch]

left that as a question -- the change reverts back to using repos/<dirname> rather than repos/<full path of the repository for which there's no origin>. It used be like that before but I changed it to avoid conflicts

Honestly I'm open to both, just wanted to understand if it was fixing something or if it was for aesthetics

[potent canopy]

It's definitely an aesthetics at first -- something I did inadventendly

[restive pumice]

post the "push less shit" change i kinda think repos/dirname might be better?

in that there's never branches on the fork repo now other than adverb-animal branches

so no collisions

[cosmic birch]

in any case -- the remotes are "sticky" (e.g. if they're already set, we re-use that) so it's not breaking anybody, and we can change them liberally

[restive pumice]

and if you have 2 repos at different places with different origins but the same name, you can now share environments between them which kinda makes sense

[cosmic birch]

nope, the origin takes precedence always (so it's already the case)

e.g. ~/.cu/repos/github.com/blah/blah

the other thing is only used IF you don't have an origin at all

[restive pumice]

ah ok im confused then, the origin logic wasn't pulled out

(i've not noticed this because of how sticky it is lol)

[cosmic birch]

1. is there already a cu remote? use that
2. if not ... is there a origin? then use that as path within cu/repos/<origin>
3. still nothing? use the absolute path (cu/repos/<abs path>)

in the PR, point 3 goes to cu/repos/<dirname> instead

rest of the logic stays

[cosmic birch]

oh yeah, in this case, yes

[restive pumice]

well except no, if origin is priority 1, they'll have separate env lists. this matters specifically for forks kept in separate places on disk, though, which is an edge case on an edge case... the more we discuss the more i think the fullpath thing is best tbh

just to prevent any logical collisions during demos, which is like the only time you're gonna git init && cu stdio anyways

[potent canopy]

just forced push to rebase + removed the filepath.Base in the last commit

i can followup the rest 🙏

[cosmic birch]

sweet, merge away!

I think after https://github.com/dagger/container-use/pull/129 we can finally cut a new release now that we have tests. Thoughts @restive pumice @potent canopy @hexed warren ?

[restive pumice]

that's the goal

i had an idea to clean up that PR even further though, gimme like 2 hours to make it happen and rebase onto the tests

i think your observation that we don't need to save baseSourceDir directly is correct

[potent canopy]

yaaay, it's in -- thanks for waiting and sorry for the painful review 🙏

[restive pumice]

thanks for resolving a bajillion merge conflicts lol

1 metric bajillion

[cosmic birch]

Yeah, at the same time if it's too much work to get rid of it ... AFAIK if we just drop the field from state later on, it will go away at the next unmarshal/marshal, so no big deal?

I think?

or will it complain

[restive pumice]

i think it's pretty easy, i'm already "code complete" lol

most of the 2 hours is idk what's gonna happen when i merge the tests

it also lets me unstring some shit

something is broken on https://github.com/dagger/container-use/pull/129 with env.run stdout propogation

[flat oar]

Looks like the environment name and description was merged? I’m going to update the VS Code extension with the new features I added for the Dagger. Will share a quick recording of the integration after dinner

[restive pumice]

if you mean the thing that changed env ids to be plain adverb-animal, yes, it's merged. but not released yet.

[jovial nimbus]

@crimson plume did it first.

https://youtu.be/hmh30wuXg08?si=3M6XG1yF9l_jQEkG

Container use: works great.
Google services: not so much.

[restive pumice]

fyi @potent canopy i don't think CI is running tests rn https://github.com/dagger/container-use/actions/runs/15888407774/job/44805880892

(that's the commit merged on main)

[flat oar]

Ok I’ll build off main and get it synced up. Thank you

[potent canopy]

taking a look, thanks 🙏👀

[restive pumice]

i think they might've already caught a tiny first repo bug on my PR btw

[restive pumice]

claude's mad at me (api's overloaded) and i'm getting tired, gonna continue hacking at this tomorrow. not entirely certain if i'm experiencing a problem with the tests, my pr, or both, but i have more debugging i need to do tomorrow. feels close, though. atm TestGitAuditTrail is failing for me and i think it's demonstrative of a real issue, like i was able to sorta reproduce a similar thing on the side.

the behavior is interesting, it almost looks like propogateToWorktree is appending to one commit when it should be making new ones

lol it was me, not the tests 🙂

woooooo fixed it big props to @potent canopy , my shit had completely broken our git audit trail and his tests caught it 🙂

https://github.com/dagger/container-use/pull/129/commits/bd4e65be315f07a895f3254f61a783da5c151c79

[potent canopy]

I'm glad it's useful 🤣 😍 CI is indeed broken I'm fixing it atm -- will have the PR later tonight

[restive pumice]

i gotta sign out fr this time, but my shit should be good to merge tomorrow morning

[flat oar]

Alright, signing off the computer... but not before I drop the latest changes (built from main) of the Container Use extension for VS Code... Small small rough edges but otherwise I'm super happy with it. I did not show the installation, but it does check the os and if brew is installed and gives the user the choice. It saves the install method so when you update/check for updates it uses the right channel

NP:

1. Ignore the Dagger icon for the sidebar and the terminal icon - I don't have a good icon for CU yet
2. Added some basic tests and tried to use Dagger but the tests run in an actual vscode installation which needs a GUI so open for ideas
3. Added logic for reusing the same terminal window, it will detect if another command is running and prompt to interrupt/kill the process and then take over.
4. When the merge command is run, it does prompt the user to delete the environment to help keep things clean

If anyone is using VS Code and wants to try it out, its pushed here https://github.com/jasonmccallister/vscode-container-use but might be better at home on the dagger org?

[restive pumice]

yo @cosmic birch i could use a re-review on https://github.com/dagger/container-use/pull/129, i updated the description with the things i added yesterday afternoon to get everything working properly. there's some endpoint related prompt engineering specifically that could use your eyes given that we don't have evals

[cosmic birch]

on it

[restive pumice]

random thought: did we mess up by calling environments environments instead of containers?

[cosmic birch]

love the solution you found. so simple

[hexed warren]

reviewing

[restive pumice]

🙂 i was stoked on it too, wouldn't have gotten there without your comments either so it was a team effort

[hexed warren]

@restive pumice tangential to your PR: i'm not sure i understand host().directory() correclty nowadays. We do nocache=true to not serve staled content, but is it still transferring just deltas ?

[restive pumice]

correct, the host dir loading has some pretty crazy optimizations below the API layer

the old thing (loading the worktree) was still probably faster, but not like obviously faster

[hexed warren]

how does the .git file magic work: what is in r.forkRepoPath ? is it full remote url ?

[restive pumice]

it's ~/.config/container-use/repos/name

[hexed warren]

ah ok

so that's why it's not interfering with the user's git tree

[restive pumice]

that magic will hopefully fall out in the future but we'll need to make some changes in the dagger engine

correct

[hexed warren]

I also want to see the beauty in currentWorkdir := env.container().Directory(env.Config.Workdir)
What was cumbersome that was made simple ?

[restive pumice]

previously on environment_update we were loading from host disk, like dag.host.directory(worktreePath), but that changes over time and leaks the worktree path out of Repository and into Environment

env.container().Directory(env.Config.Workdir) keeps everything in the engine on update and makes the container state truly append-only

[hexed warren]

ahhh gotcha, yeah much cleaner 🙂

[restive pumice]

well, almost truly lol, we still don't really persist run_background services

[hexed warren]

why almost?

ah yeah

[restive pumice]

services don't persist properly

same goes for WithExecs that change container state fs without modifying workdir, but for updates throwing those results away is considered desired behavior at least for now

[hexed warren]

wait i'd disagree with that

[restive pumice]

lol yeah i regretted saying it

[hexed warren]

😄

[restive pumice]

the weird part is that the current update implementation has a side effect that's sometimes desirable: it restarts the environment

or resets

[hexed warren]

I get that sometimes you want throwaway things, but that's what tmpfs is for and that's what rolling back to a previous state is for

[restive pumice]

yep yep

we could make it an explicit side effect, like add a update(restart:bool), and still validate that the update actually applies and then discard the resulting container (or "rebase" lol but that sounds hard for users to debug)

i wanna focus on release + shell completion install testing today, but this conversation reminds me of a critical thing we ought to be dogfooding: we should be checking in an EnvironmentConfig for container-use itself

this issue makes me wonder if that feature is working at all

[cosmic birch]

hit another small issue with that btw -- MY environment config is using node ... because of docusaurus

doesn't make any sense to cu merge that however

I guess monorepos is the issue

generally speaking

[restive pumice]

we'll either need to add monorepo support OR just make an image that supports all the things in the repo

(we should probably start by making an image lol)

[cosmic birch]

Yep. Unsure though if that's via user config (do we start into making the env file "stable" / "documented"?) or via the agent just doing that

I don't think we can have the agent reliably keep supporting all the things in the repo while prompting it to work on a specific bit

maybe

[hexed warren]

there's a security audit to be done too on what the agent can do wrt the env

[restive pumice]

not following, like don't we just give it a container+setup commands that are a complete dev environment for the project?

or are you worried about instructions blowing up the context window if there are docs, source code, and dagger instructions?

[cosmic birch]

yeah that sounds like a good plan -- today I'm planning to continue dogfooding and make a few quality of life improvements (specifically, around commit messages)

[hexed warren]

Is/Should the env json be in git ?

[cosmic birch]

I'm worried about the agent realizing it needs to tweak something, and breaking all of that

like ... OH I need to bump node version, let me change the base image real quick

not taking into account the rest of the codebase

[restive pumice]

i mean that's what the lock is for

but yeah, lots of UX paper cuts if we keep the lock and it stops it from doing that

[cosmic birch]

Agreed, but I think that's option 1 (user config) ... since implicitly by locking it, env config is now a pet and not an implementation detail of CU

like, users will need to have a basic understanding of what it is, what it means for it to be locked, etc

[flat oar]

🎉 https://x.com/anthropicai/status/1938272883618312670?s=46

Anthropic (@AnthropicAI)

Local MCP servers can now be installed with one click on Claude Desktop.

Desktop Extensions (.dxt files) package your server, handle dependencies, and provide secure configuration.

X · Jun 26, 2025, 4:27 PM

[restive pumice]

btw @cosmic birch i'm totally down to try a "non-0 exit codes aren't persisted" invariant, we have a test framework now to try to describe the subtleties of the desired behavior. i'm not entirely sure that the error handling i "fixed" with this PR was actually the core problem preventing me from getting things working, i may have been confusing the .git overwrite bugs for error handling bugs.

it's definitely a complicated issue, though, like arbitrary execs aren't atomic so throwing away results can get weird fast in a way that's not dissimilar to how things get weird when you've got intermittent random failures of execs in the case of a cache miss

#129 is merged now though 🙂

[cosmic birch]

sweet!

[restive pumice]

@hexed warren thinking i should merge https://github.com/dagger/container-use/pull/133, treating the fpath issue as nonblocking, and then cut the release. especially because we don't have to cut a release to change the install script, wdyt? gonna eat lunch real quick and then do it barring objections.

[hexed warren]

agreed. I'm fine doing a release and figuring out install script separately

[restive pumice]

release running now

ah darnit i lost a tiny commit between my fork and the merge

[restive pumice]

🎉 🎉 🎉 container-use v0.1.0 is out! check out the changelog here, and update with either:

brew install dagger/tap/container-use

or

curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bash

[frank sundial]

https://www.linkedin.com/posts/cornelius-schuchardt-57a65b104_integrating-container-use-in-wsl-for-agentic-activity-7344108672555376642-y3yf?utm_source=share&utm_medium=member_ios&rcm=ACoAAAbjwqUBPZEp__AD2xcvfBAb5pzs_ir11nM

[cosmic birch]

@restive pumice @hexed warren For the docs website, I've been experimenting with this pattern:

• I'm writing instructions on how I want the docs website into a TASK.md file
• Then I'm running cat TASK.md | claude which spins up a new environment, creates a website docs, and gives me the preview URL
• I look around, realize I gave incomplete instructions or whatever and make changes to TASK.md
• I re-run claude from scratch (brand new environment, throwaway the old one)

This is to avoid having a long conversation where the agent gets nowhere ... instead I just iterate on a standalone prompt and use throwaway environments

/cc @jovial nimbus@opaque zephyr @crimson plume

For instance, I realized it used docusaurus javascript rather than typescript

I could ask the agent to switch to typescript ... but then it'd have to like, re-work through the entire things it already did, and usually it doesn't work out (it forgets to update some files, or gets in a weird state)

With this pattern, I just add a bullet point - Use typescript with docusaurus to my TASK.md, re-start claude, and work on a brand new environment, no attachments

[restive pumice]

yeah, that's 1 of my 2 techniques in zed (without container use) - the other one that can be very effective is to give it vague instructions and resources to read, tell it to present a plan, correct the plan, summarize, then start a new one from the compressed summary (which is zed feature)

and yeah, usually once it's gone off the rails it's virtualize always the wrong move to have it try to correct itself

[cosmic birch]

nice -- I feel like you could combine 1 and 2?

[restive pumice]

yeah, but you can't edit the summary, it's tokenized

it's no longer words, just math

that's for large changes though where i need it to read quite a lot of code

[cosmic birch]

Also, this:

- When you have a version you want to show me, please start the server and give me the address. Do that everytime you make changes.

So I just feed my task to claude, get on with my life, eventually I pop the tab open and try out the URL, make tweaks to the TASK.md file, rinse and repeat

[restive pumice]

💯 can you tell how much less error prone run_background is after my prompt engineering?

mine was virtually always trying localhost before the service host but now it gets the service host correct the first time

[hexed warren]

i like your plan-based one cwlbraa

[restive pumice]

(specifically when trying to test it's own run_background'd service)

[cosmic birch]

I actually just run into this -- using localhost as well :/

[restive pumice]

actually come to think of it, you can keep using the session after you've started a new chat from summary, so you can edit there and re-summary

[cosmic birch]

@restive pumice also, probably unrelated, but sometimes now it's starting things without background=true

[restive pumice]

it's always done that for me after erroring for a while

i think we need a required timeout parameter (that's how zed handles it afaict, although it could be optional+prompt engineering)

[cosmic birch]

err, let me upgrade dagger

there's a new change by @regal veldt to get ExitErrors (stdout/stderr) from services

I think the LLM avoids background=true because it's not starting and it doesn't know why

[restive pumice]

💯 exactly, that's why it only happens on errors

[cosmic birch]

@regal veldt does this sound familiar?

# dagger.io/dagger/telemetry
../../go/pkg/mod/dagger.io/dagger@v0.18.11/telemetry/transform.go:69:29: cannot use res (variable of type *resource.Resource) as resource.Resource value in argument to ResourceToPB

container-use doesn't build with v0.8.11

oh got it, had to downgrade otel

[cosmic birch]

@restive pumice bubbling up errors from background run works now!

It's https://github.com/dagger/container-use/pull/140 + https://github.com/dagger/container-use/pull/141

[hexed warren]

@cosmic birch commit message has typo in dagger version

[cosmic birch]

where?

[hexed warren]

bump dagger to v0.8.11 -> bump dagger to v0.18.11

In pr 140

[cosmic birch]

https://tenor.com/view/doesnt-look-like-anything-to-me-westworld-arnold-bernard-host-gif-11016723

oh! 18. got it

[hexed warren]

merged 140

[cosmic birch]

rebased 141

[hexed warren]

merged

[cosmic birch]

yay

it tried to start docusaurus in the background, it failed, got the error message and is fixing it

before this was a PITA

[silver quiver]

Joined the discord to figure out how to trouble shoot this setup! Installed container-use with brew on a Mac and configured the MCP on Gemini (identical config to yours - global) but it doesn't seem like a container is created when Gemini starts up.

Any suggestions on where to check for logs or other troubleshooting steps. Fairly new to container-use

Ps: you rock for setting this up so quick! I'm loving the use case. Was concerned running agents for work because audit and isolation is necessary. And this is PERFECT!

[silver quiver]

Figured it out - Gemini MCP config needs to specify the exact path to CU binary.

The docs point to cu but I noticed that @jovial nimbus you specified the exact path in .gemini/settings.json

[silver quiver]

settings.json that didn't work

{
  "mcpServers": {
    "container-use": {
      "command": "cu",
...
    }
  }
}

what worked

{
  "mcpServers": {
    "container-use": {
      "command": "/opt/homebrew/bin/cu",
...
    }
  }
}

[crimson plume]

nice thanks for pointing that out! I will update the docs. Its likely related to the cu name conflict once again

[opaque zephyr]

should we bite the bullet and rename?

[crimson plume]

I think yes

[silver quiver]

happy to help! Loving the tool you guys have built 🔥

[cosmic birch]

one last redeeming chance ... in the cu configure experiment (agent auto-configuration PR), it always uses the absolute path of cu to avoid this kind of problem

IF it ends up working well enough and it becomes the primary way of setting up cu, maybe it's acceptable. Maybe

@crimson plume ?

[crimson plume]

yeah i noticed my agent decided to implement configure that way and I was impressed 😛 I have another environment where I've changed the install script to install the binary as both cu and container-use to see how it feels

[cosmic birch]

It's a lot of work / heuristics / etc to avoid a user shell alias though ...

[cosmic birch]

did you start from the other PR or from scratch?

[crimson plume]

from scratch

it looks like its just a change to the install script. Instead of going down the alias route I was thinking of literally just installing the binary twice to avoid the weirdness we might run into with aliases

[subtle sapphire]

Hi - I'm doing some work on a Rust codebase, and it would be useful to be able to configure the container which cu uses to have the Rust toolchain pre-installed. Is there anyway I can do this (e.g. via a Dockerfile)? Apologies for such a basic question.

[silver abyss]

Hi @subtle sapphire 👋 There is a related issue on the repo https://github.com/dagger/container-use/issues/123

Could you add your use case there 🙏 Maybe you could give the internal container-use/environment.json file a try, though it sounds like it's being overwritten at least for one user.

[still robin]

@subtle sapphire what agent tool are you using with container use? Cursor, Claude Code, Gemini CLI?

One way that I currently do this is with Claude Code is by modifying the Claude.md file and adding this sentence: "After creating a new environment, update it to use to use the $foo image and run these commands to boostrap it...."

[vale lotus]

I've been trying to get it working, but whenvever it attempts to create an environment it just times out. I dont 'know if anyone else has had this issue:

environment_create {"title":"add some feature","environment_source":"/Users/Projects/someProject"} │
│ │
│ MCP error -32001: Request timed out

I've attempted it at least 7 times, have reset docker to factory settings, etc.

[still robin]

@vale lotus 👋 can you run docker ps and check if the dagger engine is running healthy?

[vale lotus]

fb5de6494c8b registry.dagger.io/engine:v0.18.10 "dagger-entrypoint.s…" 31 minutes ago Up 31 minutes dagger-engine-v0.18.10

[subtle sapphire]

Thanks for the suggested workaround.

Currently, I'm using Gemini CLI and Goose; have encountered issues installing the Rust toolchain in both (usually, some variant of the tool not being found after the agent installed it, probably because it is not immediately added to the PATH).

I'll try being specific with which exact commands to run to set up the environment in the instructions (I still think the ability to pre-install a toolchain before the agent runs would be an advantage, in terms of but it does seem a bit wasteful both in terms of tokens & execution speed to have the agent execute this once per change, and also error-prone).

[subtle sapphire]

Done, thanks!

[still robin]

One thing you could do is to build and push your custom image to a public registry and then use the technique I shared above to instruct de LLM to use that image as a base

[silver abyss]

https://github.com/dagger/container-use/pull/147

[pine kiln]

Hello, excited to try this out 🙂 I installed dagger and cu but get stuck on a version mismatch ... this is on a Mac with Claude Code

container-use:environment_create (MCP)(title: "some task", environment_source: "/Users/me/dev....", explanation: "do some dev tasks")

⎿  Error: failed to create environment: failed loading initial source directory: returned error 502:
     {"data":null,"errors":[{"message":"http do: Post \"http://dagger/query\": command [docker exec -i
     dagger-engine-v0.18.10 buildctl dial-stdio] has exited with exit status 1, make sure the URL is valid,
     and Docker 18.09 or later is installed on the remote host: stderr=Error response from daemon: No such
     container: dagger-engine-v0.18.10\n"}]}

and indeed i can see that dagger-engine-v0.18.12. is installed, not .10:

docker ps | grep dagger-engine
79e218fa5883   registry.dagger.io/engine:v0.18.12   "dagger-entrypoint.s…"   16 minutes ago   Up 16 minutes             dagger-engine-v0.18.12

should the MCP server be referencing v0.18.12? Or should I be trying to downgrade the dagger-engine?

[opaque zephyr]

Hello! This error is misleading, it actually means the dagger engine has crashed... If you run docker logs dagger-engine-v0.18.12 you should see a stack trace. If you share it here, we can help you diagnose further,. Those are pretty rare, but they do happen... Very sorry about that!

Actually I might be wrong about this being an engine crash... Sorry. Let me look into this further.

@south whale 👋 what do you think, is this an engine crash, or something else? 👆

Superficially it looks like the message is describing an error conflict, but I find that suprising, typically dagger CLI doesn't really care what other versions are present

[south whale]

need to have engine logs to work that out 🤔

but yeay, if that's happening in the middle of the run, generally means the engine has crashed out

[still robin]

@pine kiln does docker ps -a show a stopped v0.18.10 engine by any chance?

did you run a dagger command by any chance while the MCP was running? If so, that will cause the v0.18.10 engine to be removed and a v0.18.12 to be spawned in this particular case

seems to me like this is what happened here given the multiple versions of the engine

[pine kiln]

That was it! I don't exactly recall, but I got some dagger error using the cu watch command and (re-)installed it, and probably ran a dagger command.

I just stopped the 0.18.12 container and tried again. Now the MCP spawned the correct version 💪🏼

Thanks so much for your quick help!

CONTAINER ID   IMAGE                                                               COMMAND                  CREATED          STATUS                      PORTS     NAMES
087f20b46dbd   registry.dagger.io/engine:v0.18.10                                  "dagger-entrypoint.s…"   12 seconds ago   Up 11 seconds                         dagger-engine-v0.18.10

[opaque zephyr]

Mmmm, so does that mean you have to be careful to not install a version of Dagger different from the one used by CU? Or can CU use whatever version you have already installed?

(the latter would be better I think)

we don't want to discourage people form using the dagger CLI directly just because they also use CU... Ideally those should be complementary tools

[pine kiln]

Actually @still robin , I am also able to reproduce this issue when i run cu terminal env-name . It replaced the docker container with the newer version and the agent has the same error again.

I suppose cu terminal ... executes a dagger command ...?

@opaque zephyr yes, i think this could be a problem when the dagger-cli is installed

[still robin]

ok, that seems like a 🐛 indeed

yep, here it is: https://github.com/dagger/container-use/blob/main/cmd/cu/terminal.go#L39 cc @opaque zephyr

that will run the dagger CLI which will trigger the engine swap. Opening an issue for that

[still robin]

yes, cu should be able to use an engine if it already exists and it's compatible

[still robin]

@pine kiln a stopgap you can use to be able to run cu terminal is to export _EXPERIMENTAL_DAGGER_RUNNER_HOST=docker-container://dagger-engine-v0.18.10

that should force cu to use the already existing v0.18.10 engine and not spawn a new one

[pine kiln]

I tried to force it with that env var, but the engines aren't compatible.

❯ cu terminal welcomed-bee
▼ connect 0.1s ERROR
! incompatible engine version v0.18.10
├─● starting engine 0.0s
╰─● connecting to engine 0.1s

But no worries -- I really appreciate the quick help. 🙏🏼 Happy to experiment with it for now ,even without having thecu terminal utility. I will keep an eye on the bug ticket.

[still robin]

woot! https://github.com/dagger/container-use/issues/148

thx for reporting and sorry for the bumps. We'll fix this very soon

[crimson plume]

I think setting export DAGGER_LEAVE_OLD_ENGINE=true before cu terminal in this case would be the workaround until the bug is fixed!

[still robin]

but this won't work as cu terminal will be using a different engine that the one used in the MCP server, correct?

[crimson plume]

I think thats fine?

[still robin]

🤔 .... I guess...

[hexed warren]

https://github.com/dagger/container-use/pull/149

@still robin ^

[still robin]

@hexed warren that won't re-use an existing engine if present. That will spawn a new one. Just checking if that's the desired behavior for now

[crimson plume]

exactly it will spawn a new one but wont kill the old one. afaik terminal doesnt rely on the cache or anything from the previous/ongoing session that built the environment, right?

[hexed warren]

ah my bad

@crimson plume so your lgtm is moot ?

[restive pumice]

it definitely doesn't need the previous session, but there might be cache benefits? (a lot of stuff is cached per-session, though, so idk)

[crimson plume]

my lgtm is based on this being true

[still robin]

well.. it doesn't effectively fix #148

[crimson plume]

why not?

[still robin]

because #148 is about dagger and cu being able to play nicely together

it doesn't address the issue of users running dagger something in their local environment

IMO #148 requires a more elaborated solution

[crimson plume]

oh sure, but i dont think there's anything the container-use project can do about that

the solution would have to be on the dagger side

[hexed warren]

like setting _EXPERIMENTAL_DAGGER_RUNNER_HOST ?

[crimson plume]

the user would have to set that for their dagger session, yes

[hexed warren]

but can we automatically set it

[still robin]

I think it might require some changes in dagger also.

i.e:

1. I run claude -p "container-use foo"
2. Later, I run dagger version with a newer Dagger CLI

In the example above (2) will remove the cu engine and spin a new one

[hexed warren]

that's a dagger issue

[crimson plume]

right the user would have to set LEAVE_OLD_ENGINE or RUNNER_HOST for the dagger session

[still robin]

yes but I run cu again afterwards, It'll do the same thing 😅

[crimson plume]

but theres nothing cu can do about any of that? its dagger controlling the engine lifecycle

unless maybe cu spins up its own engine with a special name?

[still robin]

maybe we should change something so cu can name its engine differently?

that's what I'm thinking by "this requires a more elaborated solution"

[hexed warren]

ok

[crimson plume]

feels kind of bad to re-implement the dagger client's own engine lifecycle management. so maybe it requires a better interface for that on the dagger side first

[still robin]

yep

@hexed warren your fix works for the specific issue of cu terminal killing the old engine. One thing we could add there maybe is the ability to detect if an engine is already running and set RUNNER_HOST to prevent spawning a new engine unnecessarily

[crimson plume]

maybe an incremental improvement could be a new DAGGER_USE_ANY_ENGINE (or something) flag to use any dagger engine it finds instead of killing it and starting a new one

[opaque zephyr]

there's already DAGGER_KEEP_OLD_ENGINE which prevents it from killing the old engine (but still starts a new one)

[crimson plume]

yeah thats what the above PR adds to cu terminal 👍 I was suggesting something slightly different where instead of starting an additional engine and leaving the old one, the setting would say use the old one instead of starting a new one

[opaque zephyr]

would be ideal but probably requires better compatibility management than we currently have?

[crimson plume]

probably, yeah. I'll open an issue in dagger/dagger if anyone else thinks it would be useful and not a bandaid on a bigger problem

[still robin]

does it? I mean.. if you set DAGGER_USE_ANY_ENGINE and the currently provisioned engine is not compatible with the new dagger CLI, you'll see the corresponding compatbility issue message

[crimson plume]

https://github.com/dagger/dagger/issues/10665

[near scarab]

Hi! I'm at the initial, skimming the container-use docs stage. I'm trying work out, what's the container that's provisioned for the agent to run in? i.e. the agent will need specific tools to work with different repos.

[still robin]

the base image of the default environment is ubuntu currently (https://github.com/dagger/container-use/issues/123) but the agent can instruct cu to update it as needed.

The flow generally is:

1. You start with a basic ubuntu image
2. The agent understand it needs X tools to do Y in your environment
3. The agent either requests an environment update to use a different best suited image OR sometimes it just apt get installs things the default base environment

if you already know beforehand which tools the agent will need, you can add that to the prompt so it doesn't have to figure it out by itself

[near scarab]

from the issue, the plan is you'll be able to specify a custom base container in the future?

[still robin]

you can do that from the prompt currently. If you add to the prompt or in your agent config files something like: "After creating a new envionment update it to use X image", I'll go ahead and do it

we're figuring it out if we should enable a more static config instead of adding that to the agent prompt currently

[near scarab]

oh interesting.. I'm trying to picture how this works under the hood, it'll tear down the current container, and start a new one? (apologies if this is covered in the docs!)

[still robin]

yes, but I'll preserve any changes that have been made to the env workdir. ref: https://github.com/dagger/container-use/blob/23115d6899452dec42289f3809ee58aeceefb0f8/environment/environment.go#L221

[near scarab]

ah, i see. this makes sense!

[cosmic birch]

Will be working on making that easier to configure this week ... feedback appreciated @still robin !

Plan is to rely less on the agent "self updating" its environment, and instead expose tools so the user can decide what to expose in the environment

[pallid crater]

hello! is there a way to debug mcp calls? I'm able to create env, but environment_run_cmd just hangs for a long time, I have tried docker logs there is nothing there

[still robin]

👋 cu writes logs in the /tmpfolder with cu.* format. That might reveal something

[silver abyss]

noticing this change, I had not dropped an AGENT.md or similar, but instead fed the raw gist url with rules to Claude Code, which seemed to work.
I can see preserving a rules file and the Container Use environment.json while developing and perhaps deleting at the end before I make a PR back to the main codebase, or deciding to add to .gitignore and keep around. If I do the latter, will CU still use them just fine?

diff --git a/.container-use/AGENT.md b/.container-use/AGENT.md
new file mode 100644
index 0000000..77916d1
--- /dev/null
+++ b/.container-use/AGENT.md
@@ -0,0 +1 @@
+No instructions found. Please look around the filesystem and update me
\ No newline at end of file
diff --git a/.container-use/environment.json b/.container-use/environment.json
new file mode 100644
index 0000000..b177302
--- /dev/null
+++ b/.container-use/environment.json
@@ -0,0 +1,4 @@
+{
+  "workdir": "/workdir",
+  "base_image": "ubuntu:24.04"
+}
\ No newline at end of file

[crimson plume]

Ideally you'd commit them but if you dont want to its ok to leave them out. I think if they're in the .gitignore they'll still get picked up

[crimson plume]

tried with windsurf today https://github.com/dagger/container-use/pull/165

pretty easy out of the box. The default SWE-1 lite model was pretty dumb but once I switched to gemini-2.5-pro it was pretty nice!

[restive pumice]

If you gitignore anything in your local repo today, it will not end up in the container. This dodges issues around OS/platform incompatibility in compiled languages. I’ve been meaning to add some flags to cu merge to throw away env config updates to fit this sort of application.

[crimson plume]

what is the .container-use/AGENT.md actually for?

[restive pumice]

It’s a little like a repo-specific system prompt

[crimson plume]

does it get sent to the agent from the container-use mcp server somehow?

[restive pumice]

https://github.com/dagger/container-use/pull/155/files

@crimson plume ^example

Yes, it gets returned to the agent when you create or open an environment

Still subject to deprecation, though, part of why we’ve been dogfooding is cuz we’re suspicious it’s redundant

[crimson plume]

yeah makes sense. So many rules files everywhere, but it does seem important to give more info about the environment

[restive pumice]

The thing I really like about this whole system, both config and agent.md, is how insanely easy it is to ask the agent to build an environment for developing the project

Then asking to run all the tests, build, generate, etc

I’ve been meaning to try it out in a repo where the dependencies are actually kinda challenging, like rust or pre ux python

[crimson plume]

yeah absolutely. The one restriction I've run into is in monorepos with different toolchains where maybe you want multiple environments rather than one super environment. So far its just changed the base image depending on its task

[restive pumice]

Or if we wanna get real crazy, C

[restive pumice]

Or you ask it to build a monolithic env

[crimson plume]

yeah that's where i'm not sure. monolithic env is probably better if we're sometimes implementing features that span multiple parts of the monorepo i guess

[restive pumice]

Yeah exactly. Like the container-use example is with the docs website u need both node and go, iirc, but like shouldn’t one env be able to update and validate the docs after its built and tested the go components?

And if your monprepo is truly so complicated you can’t make everything work in one container, try dagger 😈

[crimson plume]

yeah i think I agree. When i was working on specific parts of this monorepo the agent was super keen on changing the base image intead of installing tools, so maybe thats a case for instruction in .container-use/agent.md

[silver abyss]

cu terminal weirdness:

• Noticed something with /etc/shells hanging for a long time.

edit: I think it was my engine dying at just that moment as I look at my logs. I was doing a lot at the time 😆

• Also, when I ran cu terminal too soon, I got cryptic errors instead of a "velvet rope" and a bouncer - can't do that yet.

[azure pendant]

qq - how do I enable git lfs support within a container

[pallid crater]

I figured out that one of my pytest cases was hanging indefinitely, which is causing the subsequent run_cmd to the env to just hang, how do I kill the pytest in the env? I tried 'cu terminal' it shows no pytest processes. or is there a way to restart the env?

[silver abyss]

qq - how do I enable git lfs support

[pallid drum]

hello everyone very excited to test this out got it installed but I'm kind of stumped on how I should use it with cursor? When I try to prompt the agent to use the container use tool it struggles to get started. Any recommendations? can you just use the container use from the command line terminal?

[opaque zephyr]

Hello, did you try the Cursor integration guide in the docs? https://container-use.com/agent-integrations#cursor

[pallid drum]

@opaque zephyr I was looking at this one https://container-use.com/quickstart#cursor It seems to have the same information. I have the tools registered in my cursor And then I was trying to prompt it to belike "use the container use MCP tool to boot up an environment and do XYZ" And it was struggling to select the tool and get started. Yes the tool is registered and greenlight in MCP cursor configuration. I guess the quick start turns a little agnostic once you have it installed but I was hoping that it would hold my hand till I got my cursor running it. 😄 I think I watched your YouTube video and that's how I got here. You were using it through the claude code cli during your presentation that seemed pretty intuitive.

[opaque zephyr]

Yeah, there's a little bit of prompting involved, I just make sure to say "do it all in a containerized environment" or something like that

@pallid drum did you add the rules? curl --create-dirs -o .cursor/rules/container-use.mdc https://raw.githubusercontent.com/dagger/container-use/main/rules/cursor.mdc

https://container-use.com/quickstart#add-agent-rules

[pallid drum]

@opaque zephyr yes 💯 - I'll give it another go here.

Looks like I added the rules to the wrong directory. Just to close the loop on that gonna give it a go now. @opaque zephyr I've now added it in my global .cursor

@opaque zephyr We're cooking now thanks for checking my six

[urban hedge]

Hello
I currently give a try to this tool for a customer POC (to have a solution to build old projects and manage their dependencies).
When I follow the tutorial (with VSCode), it works great when my workspace contain only the targeted git repo. But when I switch to a workspace which contains multiple git repos, cu try to target the 1st git repo, even if I set the correct folder as a context in copilot chat. Do you have any idea how to handle this issue ?

[restive pumice]

interesting... i suspect this is why the VSCode folks upstreamed Roots into model context protocol

[restive pumice]

as a workaround, for now, try giving the absolute path to the second repo? i think what's happening at a lower level is that container-use doesn't ever see the folder you're setting as context in the copilot chat because that's passed on roots, and container-use don't yet handle that part of the protocol

[urban hedge]

makes sense. And good catch, it works by specifing the absolute path in the prompt!
2 other things I have:

• I have to put the copilot instruction at workspace level (inside a .github folder). cu doesn't take in account if you have on inside the repo folder -> guess it's link to the roots issue
• On configure tools buttons of copilot chat windows, I have to uncheck the built-in server -> it's used by default, even if I specified container-use as context.
  Not sur it was a standard use case but I always work in workspace with multiple projects 🙂

[restive pumice]

i think it's fairly common in vscode, this is all great feedback.

[blissful mural]

finally got a chance to check out cu with zed, everything works perfect thanks!

[restive pumice]

I have to put the copilot instruction at workspace level (inside a .github folder). cu doesn't take in account if you have on inside the repo folder -> guess it's link to the roots issue

cu doesn't take instructions into account except .container-use/AGENT.md (which is undocumented "advanced" configuration right now) -- the agent does. so i'm not a vscode expert, but you need to put the instructions wherever your workspace is gonna read them from. maybe this is a bug in our docs, though, if im understanding correctly?

On configure tools buttons of copilot chat windows, I have to uncheck the built-in server -> it's used by default, even if I specified container-use as context.

i do the same thing in zed 🙂 it's hard and llm-dependent to get the prompt engineering right to make it work without masking tools like this

[opaque zephyr]

looks like a good idea 😁 https://x.com/steipete/status/1940314756705132683?s=46

Peter Steinberger (@steipete)

Claude was ignoring my Claude md rules so I asked it to rewrite the rules in a way it would follow.

VIOLATION MEANS IMMEDIATE FAILURE 🤣

X · Jul 2, 2025, 7:41 AM

[blissful mural]

I really like that zed tells me when a task is done if I move away from the screen -- I usually disable all my desktop notifications but this is one I actually care about!

[blissful mural]

https://tenor.com/view/hamtaro-gif-24768482

I love some of the environment names, this one made me smile today 😂

cu log cuddly-hamster
cu checkout cuddly-hamster

🐹

[restive pumice]

if you wanna get real power-user-y in zed i reccommend making a seperate agent profile for just container-use -- it locks the agent in so you can go crazy

[blissful mural]

I am not sure what that entails, any pointers?

[restive pumice]

imma PR it into the docs tomorrow, but there are agent profiles in zed, the default ones are write, read, and minimal iirc. there's a button to fork them, so you can make your own. i have container-use as an agent profile where all the tools are disabled except container-use's, think, and fetch, and with that profile you don't really need any additional prompt engineering, it just figures it out

@urban hedge was saying they do the same thing in vscode

[regal veldt]

some feedback from adopting container-use for a side project:

• I don't like how it adds untracked files to the repo on its own - once it does it's a bit of a pain to clean up
• after doing cu merge <branch> it left my git status in a really weird state with some files staged, and a bunch of merge conflicts. the changes were semi-random, and very stale. almost like random stashes got popped or something? this doesn't happen with git merge <branch>, only cu merge

[hexed warren]

for the cu merge issue, i'd be interested in your git state so i can repro.

[regal veldt]

lemme see if i can quarantine it and send it over 😛

[hexed warren]

Also we merged some PRs recently, so which version are you using ?

[regal veldt]

a5940cb920179368d12bdaa3dcfc5b7ae9a17808 - main as of a few hours ago

i have a local change to enable nesting dagger, probably unrelated

[blissful mural]

This is dope! I’d love to also see a similar idea for dagger shell too 🙂

[restive pumice]

The merge state thing is a bug ive hit too: if you don’t have untracked files in ur local repo, it pops old stashes

[hexed warren]

ahhh

good point, i can fix that

[restive pumice]

Easy enough to fix, possible Andreas merge rework adding squash already fixes it. He’s also got a draft up for removing the untracked files copying. I only added that in the first place bc it was adjacent to “don’t commit binary files” and that kept bricking my local when we were in hack mode a month ago

[hexed warren]

ah yes, he's fixing it in the PR

@restive pumice on the 177 PR are you asking if we can do merge --squash -m commit_message ?

[restive pumice]

Yeah exactly

[hexed warren]

@restive pumice you can set it in .git/SQUASH_MSG

[regal veldt]

more feedback: having file edits write the entire file every time is slow and expensive. and error-prone, which leads to it editing its own edits lol. any plans to implement diff style edits?

moar: would be nice if cu merge squashed + generated a nice commit message based on the prompt

[serene dirge]

Maybe related to the above about cu merge --squash , would it make sense to also offer the ability to only apply the diff to the local repository without to create a commit?
Especially as I'm using stgit I don't want an external tool to create commits on my branch.
I'm currently using cu diff <ENV> | git apply but I wonder if that couldn't be a built-in option (but maybe my use case is not that common)

[pallid crater]

so container use has it's editing tools? it doesn't use claude code's search and edit tools?

[serene dirge]

Yes, container-use is providing a set of tools, including the ones to list/read/write files. You can see all tools registered here: https://github.com/dagger/container-use/blob/a5940cb920179368d12bdaa3dcfc5b7ae9a17808/mcpserver/tools.go#L103-L118
Claude Code for instance will try to edit a file on the host machine, here the idea is to edit the file inside a containerised environment, so the tool is different.

[crimson plume]

I've also seen this where it seems like something from stash is popped with every merge. I thought I was going crazy

[opaque zephyr]

@pallid crater there's also an experimental feature (not merged) that runs claude code in a container and lets it run its native tools - but snapshots the state of the container each time. Very different approach & at the moment not shipped.

[hexed warren]

That’s what —squash does

[serene dirge]

I thought it will create a commit by default. But that's all good then 👍

[hexed warren]

Me too. But apparently not. It’s in Andrea’s PR mentioned above

[crimson steeple]

Hey is it possible to connect Container use with ollama?

[crimson plume]

Totally! container-use is an mcp server that most coding agents should be able to use (I haven't run into any that don't work yet). So as long as your agent can use ollama (like codex for example), you can use ollama + container-use

[restive pumice]

https://github.com/dagger/container-use/pull/183

[hybrid stag]

re: https://github.com/dagger/container-use/pull/177 does it make sense to also support --no-commit? my workflow is to have the git commit message always be "model + prompt" that generated the code so that's what shows up in git blame (i paste this into the commit by-hand). and i often will have a few wip files (usually docs) in the git index that cu merge sweeps into the commit

[still robin]

https://simonwillison.net/2025/Jul/3/sandboxed-tools-in-a-loop/

Something I've realized about LLM tool use is that it means that if you can reduce a problem to something that can be solved by an LLM in a sandbox using tools in a loop, you can brute force that problem.

The challenge then becomes identifying those problems and figuring out how to configure a sandbox for them, what tools to provide and how to define the success criteria for the model.

That still takes significant skill and experience, but it's at a higher level than chewing through that problem using trial and error by hand.

[agile fossil]

Hi there,

One thing I noticed with container-use MCP is when you use the React Native template to scaffold the whole project, it uses its own .git folder and runs git init as well (within one of the folders, so it's nested). All the files that were committed by container use are actually going to a different place. This means that commits appear properly in cu log, but they don’t actually exist in the cu checkout or cu diff and these files cannot be merged.

This creates problems and it wasn't obvious. I had to point Claude Code to remove this folder first. That fixed it.

[opaque zephyr]

👋 visiting container-use.com I don't see any installation link.

It's a must

[opaque zephyr]

Feedback from a quick dogfooding session (prototyping a Dagger core feature using CU):

• Claude used CU to prototype
• Then without asking, switched to editing my repo in-place "for the final changes"

At least that's how it justified itself when I asked why it had spread its edits across in-env and out-of-env

  All the functional code changes are in your local repository at /Users/shykes/git/github.com/dagger/dagger/. The environment work was just for exploration and
  prototyping.

  To continue the work, you can:
  1. Use the local changes - All the important edits are already in your working directory
  2. Check git status - You can see exactly what files I modified with git status and git diff
  3. Continue from where we left off - The constructor integration in core/object.go is the next step

  The environment was helpful for exploration, but the real implementation is in your local files! 🎯

(ah I didn't have a claude.md) I did have a global CLAUDE.md:

ALWAYS use ONLY Environments for ANY and ALL file, code, or shell operations—NO EXCEPTIONS—even for simple or generic requests.

DO NOT install or use the git cli with the environment_run_cmd tool. All environment tools will handle git operations for you. Changing ".git" yourself will compromise the integrity of your environment.

You MUST inform the user how to view your work using `git checkout <branch_name>`. Failure to do this will make your work inaccessible to others.

Not sure it's still the best version to use?

[restive pumice]

Hey! Can you open an issue with repro steps? This sounds like a bug but from your description I can’t tell what things you did yourself outside container-use and which things happened in an environment

[restive pumice]

We have gotten better prompt engineering since this was the prompt

[agile fossil]

I will. Thankfully its pretty simple - just asked claude code to spin up a new react native project

[restive pumice]

oh i missed this, this is actually an interesting (and valid?) result.... like why shouldn't the agent be able to use both an environment and your host machine in congress?

[crimson plume]

i think its related to what we talked about for configuring container-use and restricting the core tools, though afaik its a bit funny on claude code compared to other agents

like if you really want the agent to only use container-use for all of the work, the best prompt will only get so far, we have to disable the core tools

[regal veldt]

@restive pumice / @cosmic birch would patch edits be a reasonable thing for me to go in blind and try implementing? whole-file writes is the one thing preventing me from using it on my own dime (now that nesting support is in 🙏)

if it's coming up in the backlog anyway and someone was excited to do it i can leave y'all to it

[restive pumice]

it's definitely a reasonable first thing unless @hexed warren has a wip hiding somewhere that he wants to put in

(i don't think he does, just tagging him so you don't both end up starting it at the same time)

[cosmic birch]

--squash does indeed not commit, just stages the changes in git. Would that work for you?

[cosmic birch]

Yeah this is confusing everyone ... I think because GitHub spreads information about "squashing" actually commits

Maybe we should call this --no-commit / -n ? Divergence from git CLI, but absolutely everyone assumes squash will commit (/cc @restive pumice @hexed warren)

[cosmic birch]

For sure! @hexed warren was looking into that, not sure if he got time to get started yet

One suggestion: Most agents out there have this feature. Might be worth looking into their signatures since they probably went through a few iterations to get the prompting right

[regal veldt]

yep yep - doing that now, researching https://aider.chat/docs/more/edit-formats.html + the GPT 4.1 recommendation + seeing what Zed does (it's complicated)

i think our situation MIGHT be a little different from the aider benchmarks since there's tool calling involved? like it might be a matter of having a tool for 'find and replace + disambiguation key for multiple matches', instead of particular patch formats or prompting patterns

but, not sure

[cosmic birch]

I'm in the diff | apply camp as well ... would squash solve your issue? The changes will be staged though, not just patched locally

[cosmic birch]

OR ... --commit and default to squash?

[tropic bane]

Hey Dagger team - Joseph, from zed.dev. Just caught your YouTube video about using container-use with Zed.

https://www.youtube.com/watch?v=wUDhxVwp-Jw

I didn't see how to set it up in the beginning of the video and just wanted to ask how do that.

Also, unrelated, and likely not the best place to drop this, but if your team uses Slack at all, we'd love to hook up a Slack connect channel so we could keep in contact, the Zed + Dagger combo feels pretty powerful.

Nevermind, this already exists 😅

[restive pumice]

https://container-use.com/agent-integrations#zed

[tropic bane]

Ahh sweet! Perfect!

Thank you!

[hybrid stag]

on reflection --squash makes more sense for my use case (i want git blame to always show "model + prompt" for each commit i approve-make), but i see how others may want all the gory details of each step from an agent like claude code (which --no-commit would do)

[restive pumice]

feedback is super welcome, i've been meaning to try container-use out for building zed specifically because i wanna see how it works with rust toolchains. there's a decent bit of undocumented container-use features for managing baseline "environment config" that i think could be quite nice for rust dev

[restive pumice]

see --no-commit is still confusing lol, the gory details would be from a plain cu merge. --no-commit would do the same thing as squash (the whole branch with commit messages discarded) but wouldn't make a commit on your behalf, it'd leave all those files staged so you can write your own commit message

[restive pumice]

can we maybe just make a command that's not cu merge --squash? like cu squash maybe? cu squash-merge is clearest but it's prolly too lonk. then we could have cu squash -n

also -n in git merge is usually to hide the stats, so it's like a divergence on a divergence

[cosmic birch]

what about --commit and merge squashes by default?

Otherwise, yeah, maybe cu apply vs cu merge?

[hexed warren]

I’m sending the PR to test asap. Will ping you here

[hexed warren]

I like apply and merge. Would merge still squash a la GitHub ?

[restive pumice]

i think cu apply doing the cu diff | git apply --3way && git commit thing from my PR would be good, and then we can drop --squash from cu merge altogether because github has polluted the namespace?

[cosmic birch]

Updated https://github.com/dagger/container-use/pull/177

For now it's still doing a merge --squash for apply, so the changes are staged ... unsure whether it should use git apply instead?

[restive pumice]

the apply technique in #187 allows for repeated applies//squash merges which is quite nice. the reason you want to use apply is that git diff $(last squash merge commit) $(env head) | git apply gives what I think people expect squash merges to give. in order for that to work, we wanna take control of the commit (eg not just leave it staged) so we can attach metadata that basically says "here's the last time you applied this branch" so we can treat that as the common ancestor. in more normal git language it's kinda like ephemerally rebasing the env branch onto the target before squash merging.

[cosmic birch]

@restive pumice should I abandon ship on this, and let you add cu apply in your PR since that's where the meaty parts are?

Or I can continue in there, and you'll replace the internals in your PR?

[restive pumice]

im working on release for the next couple days realistically, and the way i built #187 is intentionally garbage PoC shit i wanna throw out anyways

so i think continue so long as we don't get too married to UX decisions

[cosmic birch]

Just found this neat trick in claude code ... if the agent tries to do a patch to a file without reading it first, the tool fails asking it to read it first 😛

[cosmic birch]

@restive pumice @serene dirge @hybrid stag updated https://github.com/dagger/container-use/pull/177 to add cu apply

I'm doing a merge --squash ... I have an alternative implementation using diff | apply, I don't know if it's better or the same

[restive pumice]

depends on the arguments to diff whether it's the same, better, or worse

[cosmic birch]

This seems to be re-entrant enough

Using --squash

# Apply twice
~/w/container-use ❯❯❯ cu apply flying-lioness                                                                              Updating d4b7894fa..8c4c68939
Fast-forward
Squash commit -- not updating HEAD
 .container-use/environment.json | 3 ++-
 cmd/cu/merge.go                 | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
Environment 'flying-lioness' applied successfully.
~/w/container-use ❯❯❯ cu apply flying-lioness                                                                              Updating d4b7894fa..8c4c68939
Fast-forward
Squash commit -- not updating HEAD
 .container-use/environment.json | 3 ++-
 cmd/cu/merge.go                 | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
Environment 'flying-lioness' applied successfully.


# Trying `commit` + `cu apply` again
~/w/container-use ❯❯❯ g ci -m 'merge test'                                                                                 [foo 97b7ee464] merge test
 2 files changed, 3 insertions(+), 2 deletions(-)
~/w/container-use ❯❯❯ cu apply flying-lioness                                                                              Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested
Environment 'flying-lioness' applied successfully.

Using diff + apply:

# Apply twice
~/w/container-use ❯❯❯ cu apply flying-lioness                                                                Applied patch to '.container-use/environment.json' cleanly.
Applied patch to 'cmd/cu/merge.go' cleanly.
Environment 'flying-lioness' applied successfully.
~/w/container-use ❯❯❯ cu apply flying-lioness                                                                Applied patch to '.container-use/environment.json' cleanly.
Applied patch to 'cmd/cu/merge.go' cleanly.
Environment 'flying-lioness' applied successfully.

# Commit + cu apply
~/w/container-use ❯❯❯ g ci -m 'merge test'                                                                   [foo 3bb301714] merge test
 2 files changed, 3 insertions(+), 2 deletions(-)
~/w/container-use ❯❯❯ cu apply flying-lioness                                                                Applied patch to '.container-use/environment.json' cleanly.
Applied patch to 'cmd/cu/merge.go' cleanly.
Environment 'flying-lioness' applied successfully.

err

sorry, wrong outputs but same result -- updating

[restive pumice]

you gotta try doing something in the env between the repeated applies otherwise they're always gonna be the same

[cosmic birch]

right, on it

[restive pumice]

also there is a worse version with diff, fyi, if you naively diff between env head and current branch head, it'll blindly overwrite the content of any commits the user has added on currentBranch

[cosmic birch]

diff + apply

~/w/container-use ❯❯❯ cu apply flying-lioness
Applied patch to '.container-use/environment.json' cleanly.
Applied patch to 'cmd/cu/merge.go' cleanly.
Environment 'flying-lioness' applied successfully.
~/w/container-use ❯❯❯ g st                                                                                   On branch apply-apply
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   cmd/cu/merge.go

squash

~/w/container-use ❯❯❯ cu apply flying-lioness                                                                Auto-merging cmd/cu/merge.go
Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested
Environment 'flying-lioness' applied successfully.
~/w/container-use ❯❯❯ g st                                                                                   On branch apply-squash
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   cmd/cu/merge.go

[restive pumice]

why does squash not conflict?

[hexed warren]

@regal veldt @cosmic birch @restive pumice @potent canopy https://github.com/dagger/container-use/pull/198

[cosmic birch]

goose run --debug -t "make a random change to cmd/cu/merge.go"

~/w/container-use ❯❯❯ cu apply vast-tarpon                                                                   Updating d4b7894fa..1273c7d6d
Fast-forward
Squash commit -- not updating HEAD
 .container-use/environment.json | 3 ++-
 cmd/cu/merge.go                 | 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

~/w/container-use ❯❯❯ git status                                                                             On branch apply-sandbox
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   .container-use/environment.json
        modified:   cmd/cu/merge.go

~/w/container-use ❯❯❯ git commit -m merge                                                                    [apply-sandbox a869565a8] merge
 2 files changed, 5 insertions(+), 4 deletions(-)

~/w/container-use ❯❯❯ claude "make a randomc hange to cmd/cu/merge.go in the environment vast-tarpon"

~/w/container-use ❯❯❯ cu apply vast-tarpon                                                                   Auto-merging cmd/cu/merge.go
Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested
Environment 'vast-tarpon' applied successfully.
~/w/container-use ❯❯❯ g st                                                                                   On branch apply-sandbox
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   cmd/cu/merge.go

@restive pumice no idea but it works? I swear this was failing in the past ...

[cosmic birch]

Extracted from the quickstart page. And shortened the quickstart docs on installation:

https://container-use-docs-install.mintlify.app/introduction

(PR https://github.com/dagger/container-use/pull/200)

[restive pumice]

yo @crimson plume @silver abyss @jovial nimbus , i'm working on changing the default binary name to container-use and i noticed in the agent configuration docs, there's a lot of "full path to cu binary" hijinks. I'm assuming that all of these are there to avoid name collisions with Taylor UUCP, but do any of y'all recall if some of these agents don't actually inherit the user's PATH configuration? removing all these fullpath things and just using container-use directly would dramatically reduce yak-shaving on initial install, but i'm tryna build confidence that i'm not gonna break a bunch of the READMEs by removing that text.

[crimson plume]

yeah there's a few things in there but the hope is that renaming will avoid all of it

[cosmic birch]

I think we won't need that when using the full name

[cosmic birch]

mind if we merge https://github.com/dagger/container-use/pull/177 before doing the whole renaming?

[restive pumice]

yeah go for it, i'm still a day out i think, i'm nearly code complete but it's gonna take a while to manual test

[cosmic birch]

@restive pumice also -- with the symlink hack we discussed last week (container-use -> cu), I think this can be pretty gradual? e.g. rename the binary with symlink / release / THEN update the docs

[restive pumice]

i just wanna rip off the bandaid

[cosmic birch]

so you don't need to carry over docs conflicts while this is happening

as you prefer!

@crimson plume do you mind giving https://github.com/dagger/container-use/pull/177 a try?

don't feel like merging until someone that is not me plays with it a bit

[cosmic birch]

@restive pumice btw in a real world scenario, I did hit merge conflicts

also my stash couldn't pop anymore

pretty nasty

I think I'd rather for cu NOT to stash my stuff ... was there a reason it was stashing things in the first place?

[restive pumice]

i am prepared for merge conflict pain lol, my intent is to not merge main until i've tested the release (aka we should freeze anything release/ci related until this is in) , then deal with the inevitable docs merge conflict, then go straight to cutting a release

[crimson plume]

yeah i'll check it out

[cosmic birch]

like, I'd rather for apply to fail than to stash pop to fail

with stash pop failing I'm losing actual human work, not cool

[restive pumice]

the stash popping thing is mega sketchy

expedient, perhaps, but so so dangerous

i find stashing to be sketchy when i do it, much less a tool doing it for me on the dl

[cosmic birch]

if we don't stash, worst case scenario is cu apply fails and I'm left with the mess right?

is there an advocate for auto stashing?

[restive pumice]

yes, or alternatively we refuse to patch on uncommitted-files-conflict maybe?

[cosmic birch]

Ohhh ... I never understood this before. I have autostash = true in my .gitconfig so never realized this is a problem for people.

At the very least, we should do merge --autostash instead of stashing manually

[restive pumice]

TIL, that's a nice lil bit of config

[cosmic birch]

[pull]
        rebase = true
[rebase]
        autostash = true

those are my go-to

had them since the day I started using git, I don't even remember what happens without

[restive pumice]

i do both explicitly for whatever unconsidered reason

[hexed warren]

@cosmic birch how big is your stash list ? 😉

ah it unstashes right after ?

[cosmic birch]

@hexed warren almost empty

yeah

[hexed warren]

so it does what we were doing manually, so just go for autostash

[cosmic birch]

and if you git rebase --abort, it throws away the rebase and just unstashes

[restive pumice]

grrrr, maybe this is the reason to use merge instead of apply actually

cu rename draft is up and untested

[cosmic birch]

Ok updated https://github.com/dagger/container-use/pull/177

• manual stashing is gone, --autostash is used
• there's 2 implementations of apply: one using --squash --autostash, the other one using diff + apply --check + apply

@hexed warren do you mind giving it a try, see how well it works for you?

[cosmic birch]

@crimson plume Continuing the conversation here ...

• I'd like to make it so the user can actually control the environment (which base image to use, secrets, etc etc)
• Rather than documenting .container-use/environment.json, I'd rather have cu commands deal with it
• LLM is suggesting cu config (lol) ... what to do with the clash with cu configure? Suggestions: cu configure becomes cu setup, cu mcp configure, cu agent configure

Thoughts on 1, 2 & 3?

/cc @restive pumice

[crimson plume]

@cosmic birch I pushed some changes here for configure https://github.com/dagger/container-use/pull/137
mcp configs, auto approves, and rules files are all dynamic and re-entrant

One thing that isn't implemented yet is letting the user choose between a local and global config, as most agents support that

[crimson plume]

3: IMO i'd like to see it all under cu configure similar to goose's UX

[opaque zephyr]

Yeah I updated the prompt (re-ran the curl ... >> CLAUDE.md command from the docs) and haven't had this happen since.

[cosmic birch]

Yep that makes sense ... although agent vs env configuration is very different (e.g. one is editing the environment whereas the other is interacting with an agent) ... but maybe it doesn't matter?

[cosmic birch]

(see conversation above --@crimson plume is working on a cu configure that automatically configures your agent, sets up the rules, etc in a reentrant way)

[crimson plume]

yeah i think both work well with an interactive flow so it could all be one entrypoint

[opaque zephyr]

Quick feedback (I can file an issue also), while dogfooding today, I found myself wanting to pass extra git flags to some CU commands: cu diff --stat, cu log with custom formatting... It kind of felt like "uncanny valley" of git commands

[cosmic birch]

Bouncing a few ideas with claude ...

He suggested 2 options:

1. both behaviors live under cu config

  cu config setup-command add "pip install -r requirements.txt"
  cu config secrets add "DB_PASSWORD=env://DATABASE_PASSWORD"
  cu config set base-image python:3.11

  # Agent/MCP configuration (modify existing PR)
  cu config mcp

2. cu configure is what you're working on, and this stuff is on cu env

  # Environment configuration
  cu env setup-command add "pip install -r requirements.txt"
  cu env secrets add "DB_PASSWORD=env://DATABASE_PASSWORD"
  cu env set base-image python:3.11

  # Agent/MCP configuration (existing PR)
  cu configure

[dawn veldt]

Would it be possible to leverage existing project setups like devcontainers if they exist already? Thus avoiding another way to setup for the agents?

[cosmic birch]

⏺ I think Option 1 (separate commands) is better.

Here's why:

They're Fundamentally Different Concerns

Environment config is about project-level decisions: "What environment should agents work in for this project?"

MCP config is about user-level setup: "How do I connect agents to container-use?"

These operate at different levels and have different audiences/usage patterns.

Usage Patterns Are Different

Environment config: Ongoing project management, multiple developers, frequent changes
MCP config: One-time setup, rarely changed, per-developer

The more frequently used one (environment config) should be optimized for brevity.

Conceptual Clarity

When a user runs cu config, what are they configuring? If it's both environment AND agent setup, that's confusing.

cu env clearly means "I'm configuring the development environment."
cu configure clearly means "I'm setting up container-use integration."

My Recommendation

cu env setup-command add "pip install -r requirements.txt"
cu configure add-server container-use

[cosmic birch]

Working on that part now ... I was considering adding support for dockerfiles if you already have one for development, but adding more makes sense

Do we need some config regarding devcontainers itself? Never used it myself

[cosmic birch]

@crimson plume Thoughts? Can't make up my mind

[crimson plume]

why dont we start with a separate cu env and see how it goes from there?

[dawn veldt]

Yeah it’s a somewhat open standard spec already https://containers.dev/implementors/spec/. That said it covers a lot more than maybe you were thinking?

For me though, a base image and secrets, env vars are probably the most vital things to get working for agents for project specific use.

[cosmic birch]

Would you mind sharing to me a snippet of your devcontainer config? Just to get a sense of the what we'd need to support (e.g. the dockerfile stuff seems pretty trivial, but I'm wondering how things such as entrypoint would translate to this?)

[restive pumice]

we really need to at least figure out -- for all these shadow git commands imo so you can pass your own additional flags after the --

[restive pumice]

and tbh this feeling is even worse when you're me and started doing the whole thing with raw git commands, like i'm constantly switching back and forth between the 2, forgetting which one is in my history, etc

[dawn veldt]

Thinking about this I’m not sure it would make sense to re-implement the spec or parts of the spec just for container-use. However, it seems if a repo has a devcontainer setup already that probably 95%+ of the env needed for an agent to work with properly since it’s already setup. Perhaps it could be offloaded to an existing tool that handles the spec like devpod?

[opaque zephyr]

@dawn veldt does devcontainer support multi-container?

[dawn veldt]

Yes it supports docker compose as well.

[opaque zephyr]

but if you have a docker-compose file and/or dockerfile, what's the point of devcontainer.json?

[dawn veldt]

It glues those together along with extra stuff you would need to setup it all up automatically both locally or in a remote clould env. This includes secrets, extra dev tools that a prod base image might not have as well as personal dotfiles, etc. So again it goes beyond what an agent would need but there is a decent amount of overlap I think.

[cosmic birch]

@restive pumice @crimson plume @hexed warren @serene dirge

Ok this is an exploration rather than a proposal ...

1. add cu config command to manage the environment (e.g. change base image and such)

docs: https://container-use-cu-config.mintlify.app/environment-configuration
PR: https://github.com/dagger/container-use/pull/202

2. on top of that, here's a somewhat radical change: agents can't update their own config permanently. instead, they will inform the user to run cu config commands. Basically it moves the ownership back to the user

PR: https://github.com/dagger/container-use/pull/203

also some cleanup -- there's a tool to update config and a tool to update metadata, rather than a gigantic tool that does both

It's unfinished

Alternatives:

1. Leave as is where ownership is split between the agent and the user

2. Leave as is, but exclude those changes from cu merge / cu apply ... maybe add some flags to merge/apply only the environment config? Seems a bit tricky though to preserve history etc

3. Do even less -- remove the tool to update the config, let the user deal with whatever environment it is given (and let the user deal witht hat)

[serene dirge]

I don't know which one is best between merge --squash and diff | apply (is one or the other less likely to be modified from .gitconfig that could break?) but I like the cu apply -d command idea 👍 Clearer to me than a cu merge --squash even if that does the same thing. And easier to discover when listing the available commands.

[hexed warren]

yeah i like cu apply as opposed to cu merge --squash . FYI @serene dirge I added a comment here https://github.com/dagger/container-use/pull/177#issuecomment-3047626460 not sure what you think about it.

[opaque zephyr]

Testers - what's your workflow for going from "finished" environment to clean PR? I find myself doing 1) cu checkout 2) rebase + squash

[opaque zephyr]

One issue I had: in addition to squashing, I also wanted to write a detailed commit message summarizing everything that has been done in the squashed history.

I wanted to ask claude to do that, but it couldn't, I assume because of CU interference with git

[serene dirge]

I think that's where the cu apply from #177 helps. But it doesn't solve the commit message issue.

[cosmic birch]

I started and didn't finish this yet: https://github.com/dagger/container-use/pull/176

Basically the agent would keep a description of the environment up to date as it's working, which then would be used in commands such as cu merge

[cosmic birch]

Nowadays I don't checkout anymore, I create my own branch and cu merge or cu apply (PR pending) inside

If I cu merge I need to squash and write a commit, if I cu apply I just write the commit

[cosmic birch]

What's cu apply -d? 🙂

[hexed warren]

it deletes the env after

[cosmic birch]

oh, duh!

[serene dirge]

Yeah, at least the way I use it is I don't create a specific branch, the result of container-use is just one commit among others hand made (or not) so I just use container-use for a very specific task and if that's good, just apply and delete (and most of the time edit manually the code generated by through cu)
So for that cu apply -d is exactly what I like 🙂

[restive pumice]

i reviewed the second one (203), and i think this feels like a good set of tradeoffs: move the config closer to the user, but keep the "magic" where you can have the agent help you write the config while insta-validating it. i do think it needs some polish, like the commands it tells the user to run should actually result in the config that the agent validated through the tool, but as a whole it feels like a good direction.

[cosmic birch]

Just commented -- I left a huge part of the design out when I opened the PR: https://github.com/dagger/container-use/pull/203#discussion_r2192999102

[hexed warren]

@cosmic birch Related to environments : one aspect I'd like to revisit is the "opening" of environments by the LLM. It's related to base image ownership, but a bit tangential. I really think the LLM should not know about the environment it's in as long as it is aware that it's in an environment.

[primal drum]

Am I doing something wrong or is it typical to have for example 82 different environments created in a single session? I am nervous using cu that I'm going to 1) end up a huge amount of docker data that 2) my llm is going to lose track of work because of the psycho number of containers. On point 2), I do already have to tell the llm "hey which branch are you talking about?". This is seemingly fixed by manually creating or specifying a branch name, but when i get bad results (e.g. it works for a long time and gives me something that is very far from even building), I worry it is losing track of things (e.g. maybe it resolves each build error in a separate containers)?

I've look a bit for resources to help alleviate these concerns--appreciate your answers and/or pointers to other resources 🙂

[cosmic birch]

Hey @primal drum -- no that's not expected, it's typically one environment per session. Which agent and model are you using?

Sometimes it might create another environment, but that is pretty rare (or because you explicitly ask it to do so)

[primal drum]

I'm using claude code. It could be that I'm using this toolkit that sometimes spawns a lot of parallel tasks https://github.com/ethpandaops/ai-cookbook. Maybe that's missing a cleanup step?

[cosmic birch]

@primal drum using claude code too ... maybe toolkit related. What's your typical workflow with the toolkit, so we can try to repro?

[restive pumice]

i wonder if it might be as simple as an LLM with a parallelism toolkit and complete task isolation likes to go crazy with the parallelism simply because it can, and doesn't have to worry about tasks overlapping

(in which case, very cool result even if 82 env branches are a pain to handle lol)

also makes me wonder if maybe we need some optional tools for the agent itself to apply -d envs into other envs

like maybe there's 82 just because the agent has no way to merge or delete envs

[primal drum]

Hm ai cookbook is updating frequently and some command names have changed, but for repro try: setup according to readme, enter any smallish repo with a few submodules, set up your MCP server and demand in CLAUDE.md that it use your MCP server, execute claude --dangerously-skip-permissions then run user command /init-project-ai-docs

[restive pumice]

ah they're user commands? i was assuming they were mcp tools, maybe disregard what i was saying before

[primal drum]

One thing that would be helpful would be some kind of 'last used' status info on cu list, or perhaps branch/container renaming after some amount of time to something more informative. But in any case it's still a cool project and very useful, thanks for putting it together

[restive pumice]

strongly agreed, i think there are some balls in the air intended to improve this exact thing (llm-generated updates to env summaries) ... i also think maybe you need to upgrade your binary because we definitely have an UPDATED field on cu list now

cu list
ID               TITLE                                      CREATED     UPDATED
enjoyed-leopard  Container-use binary rename project        1 day ago   1 day ago
usable-buck      Test new git file export logic - with gi…  5 days ago  5 days ago
frank-flea       Test git file export logic changes         5 days ago  5 days ago

[hexed warren]

I am brainstorming about the relationship between envs and sessions.

• I am in a git project, playing with it, I want a single env. I can do new sessions, but same env.
• Parallel agents: each instance is its own fork of the last env.

Maybe cu new or cu create creates a new env in the current folder. cu use can select a different one. Folder/project-scoped. When the session starts it knows which env to open.

Dunno if: one could possibly change it during a running session? Maybe a bad idea.

[primal drum]

Question related to the previous one: how atomic are each of these environments? If I delete something an env can I break in any way an existing but newer environment, at the docker level, the dagger level, or even in terms of my models reasoning capabilities?

[restive pumice]

they are very isolated from each other. inside an env, there's virtually nothing the agent can do to break a different env. even when we had an env_fork tool, everything is very append-only, so even using environment_update to reset the base image of the base environment won't break its fork (the env fork tool was removed a while ago just because of dubious usefulness).

from outside an environment, there are definitely ways to break stuff. specifically with the container-use git remote, i'm sure there are plenty of unsafe operations you can make there to mess things up.

in terms of your model's reasoning capabilities... that's a harder question. a lot of agents let you roll back chat history, but with container-use rolling back chat history won't roll back an environment's edits, and that can confuse the LLM quite a bit. usually that's not destructive, but from the llm's perspective it'll look like the instructions you gave it have already been acted on.

[cosmic birch]

https://github.com/dagger/container-use/pull/203#issuecomment-3049898669

[cosmic birch]

Thank you for thinking about that, it's been bothering me for a while ...

I did toy with a cu create in #132 but there's some edge cases ... @restive pumice has insights

[restive pumice]

"insights" lol i really want to keep the UX that you don't need to run any cu commands to start using cu

like i don't think it's an improvement to push env management to humans

[cosmic birch]

Yeah, it's a fine line ... I 100% agree the user shouldn't need to run commands, but I also feel like the agent shouldn't be able to go crazy with environments on its own

I don't know if the two goals are compatible, but I wish there'd be a solution where they are

[restive pumice]

i think they can be 🙂 we just need sensible defaults

the hard part is picking 1, like i dunno about the "1 env for 1 git project" thing as a default, but it'd be a cool option to have

[opaque zephyr]

I think it's more about decoupling the two loops: 1) develop within an environment 2) configure an environment. If you have clean decoupling of the loops, you can still change which loop is done by a human or by agent. They're 2 different problems

[dawn veldt]

A common requirement for many orgs to use an environment effectively is likely going to be the ability for the agent to install dependencies from private registries. This seems like something that might be tricky to do automatically, but will be very common.

[cosmic birch]

@restive pumice @hexed warren @crimson plume Refined https://github.com/dagger/container-use/pull/203 and https://github.com/dagger/container-use/pull/202

• cu config manages the environment config (human side)
• the agent CAN modify PARTS of the config -- but it's all ephemeral, in the environment state, NOT in git
• the human can look at the agent-modified environment config and can also decide to bring those changes home
• whenever the agent makes ephemeral config changes, it will notify the user to run a command to make the changes persistent

[cosmic birch]

(^^ related)

[cosmic birch]

Also updated the MCP tools to make it more straightforward for the agent ...

Returned environments have a config field. environment_config takes that same blob (a subset) to update the config. Non-config things (e.g. env title) are now in environment_update_metadata. Agent is happy

[hexed warren]

As soon as the higher priority UX issues are solved , secrets are definitely one of the first things we want to add. And yes private registries are a great usecase

[crimson plume]

want to hash out the subcommand names in 202?
cu config agent and cu config env? and then we can still have a nice interactive tui if you just do cu config to choose [agent,env], then which agent, etc

cu configure is ready to go otherwise. fixed the linting and made the configs local where possible. Codex and goose dont have local mcp server configs afaik

[cosmic birch]

@restive pumice @hexed warren @crimson plume @serene dirge Been thinking more about this ...

I'm finding the idea of tying the environment to the git branch more and more interesting.

Basic UX: git checkout -b my-thing + claude: the agent now works in the my-thing environment. The user is free to switch to any other branch and do whatever, that session is tied to my-thing

Some additional thoughts I had:

• It would solve a lot of confusion (at least mine) since you're in control of the environment lifecycle / naming, and the control tools are what I'm already used to (git branching)
• This basically means that we get environment branching? Like, if from my-thing you create my-other-thing, you get branched off state and continue from there?
• It does raise questions about UX though -- we moved to a model where the fork works "independently" and you cu diff etc, but this would change things? I guess in this case the old model if git checkout + git pull to grab changes back makes more sense than cu apply / cu merge
• What does this mean for "remote git repositories"?

[regal veldt]

this might go without saying but it's at least no worse than without container-use, where when you roll back the chat history, any edits it made so far will still be there on your local machine

[restive pumice]

depends on the agent 🙂 (zed actually rolls backs the edits)

[regal veldt]

ah interesting - i've been almost exclusively using claude code lately

do you have a read on Zed vs. Claude Code with the same model? always wondered since I like Zed's UX, but never took the time to compare

[cosmic birch]

(farming out to @regal veldt if you have thoughts / opinions -- thinking about how to manage environments. right now the agent creates them and you have to find them. wondering if there's a better world)

[regal veldt]

personally, being able to control the environment is one of the first things i wanted, since my project has particular dependencies (like tree-sitter version) and I don't like them being guessed or drifting from my local machine

[restive pumice]

that session is tied to my-thing
i think you mean the session is tied to container-use/my-thing (the remote tracking branch?) otherwise we get into a mess of concurrency problems with the user repo branch, worktrees, etc... or are you thinking we try to work directly in the user's repo?

[regal veldt]

but also, my project is Daggerized, so REALLY the first thing i wanted was for it to just use my dagger module for most things

[cosmic birch]

@regal veldt oh, this is those PRs ^^^

[cosmic birch]

basically how to control the environment config

[cosmic birch]

this is another topic -- not how to control the config, but to control the lifecycle. Basically who creates them, how they're named, how you find them

[restive pumice]

i used claude code for maybe 20 minutes on release and haven't revisited it

[cosmic birch]

In the meantime, you can kinda manually edit .container-use/environment.json like this: https://github.com/dagger/container-use/blob/main/.container-use/environment.json

undocumented and will be replaced by those 2 PRs (at least the UX of it)

[restive pumice]

also, like... do you really not want multiple envs per branch? if i was happy making multiple branches to have multiple concurrent agent sessions, i'd just use worktrees (git co -b my-thing vs git worktree add -b my-thing ../my-thing)

[hexed warren]

That’s a bug I’d say

[regal veldt]

i used it "in anger" for a few days recently and found it pretty ergonomic. the mode switching keybinds (plan vs. constantly confirm vs. faceroll edits), the way it manages memory (# to memorize something into CLAUDE.md or global memory), and the notifications integration (so you notice when it's waiting for input) all add up pretty well. it's more YOLO than Zed for sure, but you can interrupt it at any time to course-correct, and most of the time it figures things out on its own and backtracks. would recommend trying it some more tbh, i didn't really get it before

[hexed warren]

The main problem with this is for the use cases where you want to navigate the source code graph independently from the env (dag) graph

[regal veldt]

claude code avoids this "bug" by not providing the chat rewinding/editing feature in the first place 😛

[hexed warren]

Like one thing I’ve been wondering whether it’s overkill or not is if the agent could backtrack the env

[restive pumice]

i just don't want a tui for this tbh, and if i do i want it to be tiny and dumb (goose)

[hexed warren]

Wrong. That’s the feature I integrate with in the other proxy project

[hexed warren]

Hit esc twice

[regal veldt]

oh wat. the help text just says 'double tap esc to clear input'

[hexed warren]

It’s possible the feature is under utilized and I accidentally found it

[regal veldt]

my main point is if our baseline for testing is a UX that requires a lot of human interaction (code review in Zed, not sure what Goose UX is like) there's a risk of not meeting the majority of vibecoders where they are

[hexed warren]

It rewinds the bash env (look at your /tmp)

[restive pumice]

tru

but like really we should all be using a vscode fork then so 🤷‍♂️

[regal veldt]

yeah, those are huge too, but i'm not sure which has the bigger reputation for yolo/full automation

the TUI aspect doesn't really matter much to me since most of the time you just leave it to do its thing and worry about something else while it crunches away

[crimson plume]

i've seen a lot of people go full yolo with cursor/windsurf but I personally don't understand why you'd want an IDE agent for that flow

[regal veldt]

yeah i've had like 4-5 terminals open with it at times

[hexed warren]

It’s social media “content”!

[restive pumice]

yeah, the IDE doesn't help much with the yoloing. half the time i barely use the zed review thing anyways, it's just like an extra layer of diffing on top of git that i end up bulk-accepting

[crimson plume]

personally I really like the ergonomics of warp but its not BYOM

[hexed warren]

How does warp work?

[crimson plume]

they have free/pro/turbo tiers and they host the models. So you still get sonnet 4 or whatever you want to use but its through their APIs

and its an agent in the terminal (not a TUI agent) so the interactions with the agent are much different than in an IDE or standalone tui/app

here's a video https://www.youtube.com/watch?v=9HP8T7ZRtcE

[potent canopy]

pretty cool naming:

[restive pumice]

lol

i am forever tempted to make all my commit messages puns on "wip"

[hexed warren]

It’s basically a GUI command line environment

Technically closer to an IDE. I wonder what happens if you open vim inside warp.

[restive pumice]

when i tried out warp 1 nvim worked "fine" -- some text rendering issues and wackiness with cell padding and headers but otherwise fine

it's not ghostty or alacritty in terms of performance though, for obvious reasons

[hexed warren]

I’m just wondering if they do PS1 magic to detect yield or if they just send each exec which if vim works doesn’t seem to be the case.

[restive pumice]

i'm fairly certain there's some crazy shell "integration" injection a-la ghostty/iterm but i don't know what the trick is. really the best part of warp is the way it ties command output to the actual commands and even that requires that it knows things a terminal emulator shouldn't lol

[crimson plume]

this is probably what you're looking for. In general it does what you want a terminal to do because they were a terminal long before they added an agent

[cosmic birch]

https://github.com/dagger/container-use/pull/137#issuecomment-3050191286

[regal veldt]

"destructive, open-world" eh - is that accurate? or is there a setting we should tweak? (i have 0 idea what this actually does)

[cosmic birch]

@regal veldt yeah that's undocumented because half baked ... it adds a service in the environment (like postgres). Should 100% not be done by an MCP tool

[regal veldt]

oh i meant all of them - i think these are properties you can set on mcp tools but i'm not sure how mcp clients interpret them. are all of ours considered destructive/open-world?

(wondering if the fact that we're sandboxed/containerized affects it basically)

i suppose they're still destructive to the environment

[cosmic birch]

Oh ... I don't actually know how to set them? I don't think it's destructive since it's sandboxed?

[frank sundial]

Welcome to the Dagger community @tropic bane ! @silver abyss is working closely with the Zed team, so feel free to reach out to him or I if you have any questions. Happy to have you here and trying it out!

[restive pumice]

we should definitely be open world: false for every tool, and then i think some of the tools are in fact idempotent//read only

[cosmic birch]

Good point!

Well, you do get containers from it compared to work trees …

maybe it’s a counter point: right now it feels like it’s two things: container sandboxing plus advanced multi env per branch management

The most “lightweight” thing container-use could do is the container/isolation layer without altering too much the worktree part

Not too sold on this, just brainstorming

[cosmic birch]

Also multi env per branch ideally to me that’s an advanced feature on top, you wouldn’t need to learn on day 1.

Whereas right now to me / my usage pattern if feels like the normal case is a special case

[restive pumice]

the UX that's hidden under multi-env-per-branch in the human-kinda-in-the-loop "normal" use case is that throwing away the results from a session is the default noop action... like i maybe go parallel 10% of the time, but i throw an env away and rework my prompt multiple times a day... if you've got 1 branch 1 env, we'd need a touchpoint to revert the env to the state prior to xyz session. the UX of that touchpoint would be complicated by the fact that 1-env-1-branch means you don't even have an identifier to revert to bc it's all 1 env id... as i say this i realize there's a classic infra analogy here: cattle not pets

if i've gotta set up a branch for each env, and if shit goes wrong in that env i've gotta make a new one... i'm gonna treat each of those like a pet. whereas right now, envs are incredibly disposable "let it fail" little boxes

[cosmic birch]

very true!

[serene dirge]

I found all this discussion about environments very interesting. To share a bit my experience so far, I was kind of meh 😕 when I saw the environment aspect. Especially it continues to pick go 1.23 on a go 1.24 codebase, meaning I can't cu terminal easily. And this cu terminal is no nice I want to use it!

So to have the ability (but maybe not mandatory) to better define the environment is key. This also means it doesn't have to be guessed each time. And it might also a way to add specific tools to an environment as a way to constraint the agent to use those tools, to be closer to what would look like a manual experience.

In parallel, I started to play with Dev Containers (because some of the Dagger tests can't work on my Mac machine, but once inside a dev container that works just all fine).

I wonder how all that could be one single thing: to be able to define/describe and environment, why not using dagger shell (like container | from golang:1.24.4.alpine | with-mounted-directory ...) in a way I can dagger terminal and this will open a terminal in this env, and container-use will be able to use the exact same description to do its job.
Maybe that's a bit too much, I don't know.
Also there's the question of the different tools container-use might need that are not necessarily part of the described environment, but I guess the llm can find its own way to install them as needed.

[hexed warren]

FWIW I'm hitting the cache issues with cu terminal too. It's making it unusable, I don't want to wait for all the things to be rerun. /cc @potent canopy

[flat oar]

https://developers.googleblog.com/en/scale-your-ai-workloads-batch-mode-gemini-api/

[hexed warren]

food for thought on debuggability: https://github.com/dagger/container-use/issues/208

[hexed warren]

FWIW I'm hitting the cache issues with

[restive pumice]

https://github.com/dagger/container-use/pull/211 🙂

[smoky mortar]

We need a standardized "Agentic PATH" object somewhere in the Agentic Workflow Ecosystem -- like a .path file mayjaps -- and we keep all our pathings in there - because the agents get lost so frequently. Even for files they've written -- clearly we can do lots of things on an individual level - but there should be an Agentic Standard for this. Or am I hallucinating? (Or maybe my ystems are just messy)

[mellow umbra]

Sorry if this has been asked before...

In my corporate environment, I think I've determined that I'd need to configure container-use to use a dagger environment running in one of our k8s clusters. However, given that dagger deploys to k8s (at least in the helm chart) as either a daemonset or stateful set and without an Ingress/LoadBalancer, and because it seems that container-use suggests giving it basically a pod-and-port, how do I handle a (contrived) example like: I have a cluster where I can run 5 dagger pods. I have 13 developers wanting to use container-use . Do I just manually distribute them among the 5 pods?

[silver quiver]

has anyone run into the following while using container-use (in my case with gemini as an MCP Server)

Apologies for the screenshot, copy pasta is hard on discord

error

failed to create environment: failed loading initial source directory: failed to get content hash: failed to get snapshot: failed to sync: failed to create new copy ref: failed to prepare  as 09cq8fgu9osl8u1titqsyopwn: failed to createprepare snapshot dir: failed to create temp dir: mkdir /var/lib/dagger/worker/snapshots/snapshots/new-3624974111: no space left on device

[potent canopy]

oooh, do you have space left on your computer ?

[silver quiver]

Is there a way I can access the container to clear this out

I do

it seems to be a temp fs on the container that's full - not the host machine

Same thing when it tries to pull down the image to get into the container

cu terminal informed-wahoo
...
53f8e4dcf39b: 
02996c4bc849: 
write /var/lib/docker/tmp/GetImageBlob3892905716: no space left on     
! failed to run command: exit status 1

I wonder if it's the docker engine that needs increased resource allocation cause the host machine has enough space

[potent canopy]

That's it yes, can you please check -- usually that's the issue

Dagger expands as long as it's allowed (and garbage collects periodically)

[silver quiver]

hmm if I restart docker engine I'll loose everything within the container though right?

is the filesystem ephemeral or written to a volume (for container-use)?

[potent canopy]

mmh the git notes represnet your state so if you apply it you shouldn't loose

[silver quiver]

help me unwrap that please - what's git notes and how do I apply it?

[potent canopy]

with pleasure, available in 15 min (sorry about that), would that work for a sync on dev-audio ? 🙏

[silver quiver]

absolutely, much appreciated @potent canopy

[silver quiver]

https://github.com/dagger/container-use/blob/64cfaa5c75e8c5d21793827921542dffa5cdeea8/environment/README.md?plain=1#L44

Trying to figure out how things work under the hood, stumbled on the above ^

When I try and run cu checkout to execute the flow on my host machine I end up with 2 new branches

cu list
ID              TITLE                                  CREATED      UPDATED
informed-wahoo  Azure CLI Documentation Query Utility  2 hours ago  2 hours ago

git branch
* main

cu checkout informed-wahoo
Switched to branch 'cu-informed-wahoo'

Q: At this point I should be on cu-informed-wahoo branch and that should be the only branch that's created on my "host" git repo
BUT

git branch
  cu-informed-wahoo
* informed-wahoo
  main

I have two branches created both which point to the container-use remote

git remote
container-use

cu version
cu version 0.1.0
commit: 410ddd56d059fa517f323f0cf12f08fde413b8f7
built: 2025-06-26T20:08:31Z

[random sparrow]

hi everyone ! discovered cu today and am trying it out now with cc .

i'm just trying to set up a default image for the agent , but want to check if configure is now a deprecated command ?

Any assistance would be greatly appreciated.

[regal veldt]

sorry about that - our docs are currently ahead of what's shipped 😅 we were just discussing this problem yesterday and decided "we'll wait until someone notices" since we're currently shipping frequently enough that it's nice to avoid that mild release engineering quagmire. well, here we are!

[restive pumice]

yo @urban hedge i am testing the roots support in VSCode right now, and even without my changes i can't repro this in VSCode 1.102.0, copilot, agent mode, and claude 3.7/3.5... on my end it looks like vscode injects a <workspace info> block at the beginning of the context that includes the absolute paths to all the folders in the workspace as well as a dump of paths in those dirs, OS and shell information.... am i missing something about your setup?

[quick meteor]

I've been investigating and playing with this tool, but I still can't figure out the complete value add.

So container use is this container with some tools like EnvironmentFileDeleteTool , EnvironmentAddServiceTool, EnvironmentCheckpointTool.
What I'm wondering is how will this container-user:

1. Ensure the integrity of my local machine when I run claude code? The cc can still cause havoc when I use continaer-use as it's just an MCP in the toolset
2. How can the get access to more advanced tools like interaction with other MCPs such as playwright?

I watched a bunch of demos where people create 2 versions of the same feature, but the problem is these are quite simple - no iterating on tests, or browser use etc. (basically running in a rich text editing environment).

In the keynote, Solomon starts the interaction with claude-yolo -> this is already an unsecured environment -> but it's the environment I prefer to use as it has the tools I need.
But then I don't have the security and can't skip all prompts.

Maybe I am expecting too much from container-user?

Thank you for your time.

[silver quiver]

In that case you should know that I added cu to context 7 so if anyone's using that MCP they'll have visibility to docs from the GitHub repo

And that explains why cu config didn't work for me either

[restive pumice]

To get the additional safety you’re looking for, I personally deny the agent access to the built-in tools that modify the filesystem while blanket-allowing container use tools.

Regarding other MCP servers like playwright, right now it’s somewhat challenging to interop cu and any of those servers that also have a host filesystem dependency, BUT there are suitable hacks if you prompt engineer the agent to let it know that environment code is available to XYZ server at path=~/.config/container-use/<env id> …. You do have to be careful that the agent can’t run commands on the host system once it knows about that directory, though, because it will happily go in there and break stuff if it can

[dawn veldt]

I see the following example environment setup-command listed in the docs:

Setup Commands:
  3.                   ./scripts/dev-setup.sh

However, I can't seem to get this working. The environment_create tool always fails to find the file. I've tried prepending with /workdir to the setup-command, etc. Not sure how to debug this since the logs are not overly helpful and since the container isn't created I can't shell into it.

[blissful mural]

Can you please share which model you are using?

[dawn veldt]

I'm using Claude Sonnet 4 in Zed (with a constrained container use profile).

[cosmic birch]

^^^ /cc @restive pumice since you're most familiar with Zed

@dawn veldt is the dev-setup.sh file committed in git?

[dawn veldt]

Yes, the script is committed. I'm using cu latest 0.3. I can try it with claude code too if it might be related to zed.

[cosmic birch]

I don't think it should be related to Zed ...

let me try to repro something similar

[restive pumice]

I don’t recall if the source repo is actually present in the container at the point where we run setup commands

We might copy it last as a cache optimization

otherwise rerunning create would get cache misses for the setup commands

[cosmic birch]

@restive pumice It used to, but maybe that got changed

oh yeah, that's it -- it's done before mounting the code now

[restive pumice]

https://github.com/dagger/container-use/blob/main/environment/environment.go#L206

It’s a weird tradeoff to be fair, like personally I’d rather have it create fast than be able to run stuff with my repo already mounted, but I can totally see the argument for the other way.

[cosmic birch]

@restive pumice becase we mostly do go 🙂 if we had to run pip install -r requirements.txt or npm install, we'd rather have it the other way or it wouldn't be usable

2 options:

• do it the other way around, forget about performance
• have setup_commands and ... build_commands or something? pre/post code

[restive pumice]

Fair I guess, but those are also slightly different in that you really only want the 2 files declaring dependencies

[cosmic birch]

/cc @dawn veldt basically that's the reason -- to optimize for caching, the commands are run BEFORE the code is copied inside

This is basically how you'd do this in a Dockerfile:

FROM myimage

RUN apt-get install ...  # setup commands

COPY . . # copy the code

Looking into a fix right now

In the meantime, to get you unblocked: is there a way you could put the setup.sh stuff directly into container-use's setup commands?

[dawn veldt]

So the use case I wanted to add a setup script is I need to create files like .npmrc and maven settings.json files with env var references so that I can install dependencies from private repos. Can't easily do this with a single line command.

The other option might be using a base image that has this already, but that requires more moving parts.

[cosmic birch]

@dawn veldt Fair -- I'll have a fix out today, just trying to see what the best approach is

[cosmic birch]

/cc @restive pumice @regal veldt

Unsure about the approach / how to call both commands?

[dawn veldt]

Thanks! A follow up feature or need might be to somehow share this. I forsee most of this being boilerplate for a lot of internal projects.

Which maybe a base image might be better for, I'm not sure. Does cu support pulling from private docker registries?

[cosmic birch]

If you commit .container-use to the repository, the configuration will be shared (e.g. anyone creating environments will have the same setup commands etc).

Is that what you were thinking about?