Running cursor CLI in Kubernetes, trying to persist /home/user/.cursor to remote volume. Cursor CLI uses SQLite which fails on filesystems that do not support chmod and other low level.
Error shown is: [internal] SQLITE_BUSY: database is locked
Proposed solution: introduce an environment variable to govern where databases are stored (separate from regular metadata) so operators/users can workaround this issue in whatever way they prefer. I.e. restore databases on container boot and sync back to persistent storage on pre stop.
Steps to Reproduce
Deploy cursor CLI in a container. Push it to Kuberenetes. Mount the cursor home directory to an underlying storage that does not support CHMOD.
Operating System
Linux
Version Information
CLI Version 2026.04.17-787b533
Model Composer 2 Fast
Subscription Tier Unknown
OS linux (x64)
Terminal unknown
Shell unknown
User Email Not logged in
We are building persistent agents that use cursor-cli as the runtime. Because we are deploying in K8S, we need a way to persist state as containers are designed to be immutable.
To that purpose we map locations that hold state (like the cursor /home) to cloud storage. It is common that cloud storage has limitations, specially holding database files. There is storage that has full support, but the trully cloud native ones that have backing blob storage or similar have their limitations.
As a workaround, we are copying .cursor from persistent storage into the container with an init container and then back to persistent storage on container pre-stop. This is not reliable, but loosing .cursor state is not that critical for us. Besides, running SQLite on a volume backed by these cloud native storage is not very performance wise.