Cloud Agents: inconsistent Docker / Compose bootstrap on AnyOS desktop — “dockerd + compose” vs “docker not installed”; how does this relate to .devcontainer image:?

Support Bug Reports
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

I’m seeing non-deterministic availability of Docker on Cursor Cloud Agents . I’m trying to orchestrate some supporting services for development (namely postgres + redis), and sometimes the my startup.sh script reports the docker is not installed / running, and sometimes it works fine.

On working sessions, htop shows dockerd --storage-driver=vfs, docker-proxy, and containerd-shim-runc-v2. On failing sessions: no /var/run/docker.sock, docker: command not found.

Is Docker-on-host intended to be guaranteed, best-effort, or tier/pool-dependent for Cloud Agents?

Why can two sessions both show AnyOS DESKTOP INIT START yet differ on Docker installation/bootstrap? (image variant / routing / quotas / rollout)

Is there any official setting / label / pool users/orgs can choose to always land on Docker-capable agents (or explicitly choose slim agents)?

Steps to Reproduce

Behaviour is intermittent. Sometimes a cloud agent is scheduled on a virtual host with docker, other times it is not. I cannot discern a pattern as to why one is chosen over the other.

Expected Behavior

Repo workflows rely on Compose-backed local dependencies; nondeterministic host Docker breaks onboarding (migrations/seeds). We need a documented contract so we can design around it reliably.

Thanks!

Screenshots / Screen Recordings

Screenshot 2026-05-08 at 12.57.55 PM.png
Screenshot 2026-05-08 at 12.57.55 PM.png579×421 18.3 KB

Operating System

MacOS

Version Information

Version: 3.3.27
VSCode Version: 1.105.1
Commit: 80b138a7a0a948e1a798e9ed7867d76a1ba9a310
Date: 2026-05-08T02:26:22.498Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, this isn’t a bug. It’s expected behavior, it’s just not obvious. Here’s why.

Docker isn’t included in the default Cloud Agents image. So by default, it’s not in the environment. If you sometimes still see dockerd in htop, that’s due to snapshot caching. If a previous session’s setup agent managed to install Docker and that state got cached, the next session can start from that snapshot. If it starts from the base image, Docker won’t be there. That’s why it feels non-deterministic.

To make Docker available deterministically, you need to:

  1. Create .cursor/Dockerfile that installs Docker CE, Docker Compose, fuse-overlayfs, and iptables-legacy.
  2. Reference it in .cursor/environment.json.
  3. Add sudo service docker start to the start command.

A full working recipe with all packages and an environment.json example is in the docs: https://cursor.com/docs/cloud-agent/setup#running-docker

Answers to your questions:

  • Guaranteed / best-effort / tier-dependent? It’s opt-in. It doesn’t depend on tier or pool. You enable it via your own Dockerfile.
  • Why are two sessions different? Snapshot caching, see above.
  • Can I always land on a Docker-capable agent? Yes, via your own .cursor/Dockerfile. After that, Docker is guaranteed in every session.
  • Any relation to .devcontainer image:? No. Cloud Agents don’t use the devcontainer spec. We use a separate format, .cursor/environment.json. The image: field from devcontainer.json is ignored.

Related thread: Cloud agents with docker-compose

If anything fails after you set up .cursor/Dockerfile, post the setup phase logs and the Request ID and we’ll take a look.