When configuring a background agent with a snapshot that has Flutter and Dart installed, the tools are present when manually testing the environment via “Start New Environment” in the Background Agents Setup UI, but are completely missing when an actual background agent runs.
The .cursor/environment.json file correctly references the snapshot ID, and the snapshot verification step shows Flutter/Dart are installed and working. However, when a background agent executes, running flutter or dart commands in the agent’s terminal results in “command not found” errors, indicating the snapshot’s disk state is not being applied to the agent’s execution environment.
Steps to Reproduce
Start a new background agent environment via “Background Agents Setup”
Install Flutter/Dart using the Flutter VS Code extension in that environment
Verify flutter --version and dart --version work
Create a snapshot of this environment
Configure .cursor/environment.json with the snapshot ID
Test the snapshot via “Start New Environment” - Flutter/Dart commands work ✓
Start an actual background agent with a task
Run flutter --version or dart --version in the agent’s terminal
Commands fail with “command not found” ✗
Expected Behavior
Background agents should inherit all installed tools and packages from the configured snapshot.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Experiencing the same thing. It’s also ignoring Dockerfile-based configurations. I’ve resorted to just scripting my entire environment setup and running it in install. Thanks for writing the issue up, @tsteward
I’d also add that agents aren’t caching disk state after the “install” step as the documentation states they would.
It’s worth mentioning that background agents seem quite unstable in general. See Agent is unable to use sudo due to no TTY and Background Agent Docker in Docker - #18 by someguynamedmike . It feels like a bit of a moving target trying to understand how they work and where they differ from the documentation. It’s understandable if this is an early and experimental feature subject to active churn, but if that’s the expectation I wish it would be communicated out. I’ve had several times now where I spend a fair amount of time configuring them and using them for a little bit only for them to break and have to configure again, trying to infer how they work now. A feature that should be pretty powerful is ending up in a net productivity loss
