Use case · Cursor CLI · Updated 2026-10-31
Run Cursor's CLI agent inside a microVM, not on your laptop.
A Cursor agent sandbox lets Cursor's command-line agent run commands without approval while your own files stay out of reach. kosa8 lists a cursor kit that limits the network to Cursor's API hosts, but it is marked unavailable as shipped, because Cursor distributes its CLI through an install script that cannot be pinned to a digest. kosa8 agent init cursor writes a copy you finish with an install step you have checked yourself.
01Why run Cursor's agent in a sandbox?
Cursor's CLI, started with agent, asks you to approve commands in interactive mode. Its -f/--force flag, alias --yolo, will "force allow commands unless explicitly denied", which is what you want for unattended runs and what you do not want on the machine that holds your SSH keys and other projects. Cursor also has its own sandbox controls, set with /sandbox or --sandbox enabled|disabled.
A microVM moves the whole agent, not only its commands, onto a machine that sees one folder.
03Finish the kit yourself
kosa8 agent init cursor writes ~/.kosa8/kits/cursor.yaml without the unavailable line. It keeps the network limited to api2.cursor.sh and api.cursor.sh. Add a setup line that installs Cursor's CLI from the source you have checked (Cursor documents curl https://cursor.com/install -fsS | bash), add the hosts that install needs to egress_allow, and set command to the name the installer provides; Cursor's docs call it agent.
kosa8 agent init cursor kosa8 agent run --dry-run cursor
A setup line that downloads counts as unpinned, so the run needs --allow-unpinned. For something a team depends on, build an image that already contains the CLI and name it as the kit's image instead.
04What happens to CURSOR_API_KEY
The cursor kit lists CURSOR_API_KEY under secrets, so it is passed in: the real value is in the sandbox's environment, where the agent can read it and send it to any host the kit allows. kosa8 prints a warning each time. The network allow-list is what limits where it can go.
05Signed kits for a team
Because a kit file decides what an agent can reach, an organisation can sign the kits it approves and have each machine refuse the rest. Signing and pinning need the Governance subscription; checking a signature never does.
kosa8 agent sign org.key cursor.yaml kosa8 policy trust org.key.pub
06How to start
Install kosa8 and start its daemon.
Write the kit, finish its install step, check the plan, then run it.
kosa8 agent init cursor kosa8 agent run --dry-run cursor kosa8 agent run --allow-unpinned cursor
07Questions
Why does kosa8 agent run cursor fail?
The built-in cursor kit is marked unavailable: the npm package it used to install is not published by Cursor, and Cursor's own installer is a script that cannot be pinned to a digest. Run kosa8 agent init cursor and add an install step you have verified.
Is Cursor's --force (--yolo) flag safe inside a kosa8 sandbox?
It is safer there than on your laptop. Inside the microVM the agent can change only the shared folder and reach only the hosts the kit allows. It can still change anything in that folder, so commit first.
Does kosa8 keep CURSOR_API_KEY out of the sandbox?
No. The cursor kit passes CURSOR_API_KEY in as an environment variable, so the agent can read it. The kit's network allow-list limits which hosts it can reach.
Does kosa8 sandbox the Cursor editor?
kosa8 documents a kit for Cursor's command-line agent only. Running the Cursor editor's agent inside kosa8 is not separately documented.
08Guides and articles
09Sources
10Try it on your own machine
Install kosa8, write your cursor kit, and let the agent auto-run on a machine that is not your laptop.
Updated 2026-10-31