Set up/tear down external resources (e.g. DB) for each cloud agent

Support Help
,
1

Hi,

I’d like set up and tear down external resources (a database for example) for each cloud agent. These resources would be set up before an agent does its job and torn down after the agent is finished.

Is it doable? I tried with Dockerfile and some setup.sh script, but it seems there is no way to destroy resources after an agent is finished.

Ideally if it would be possible to run a script when an agent starts and another script when the agent finishes. Alternatively a script to runs and lives as long as the agent lives.

EDIT: Is there are way to get agent ID when the install command is executed?

Thanks in advance!

3

Hey, good request.

Right now, Cloud Agents don’t have a built-in on finish callback. There is install also called the update command in the docs and start or terminals to run on startup, but teardown when the agent finishes isn’t supported natively.

Here’s what you can do today:

Setup: use start in environment.json or terminals to bring resources up. start runs on every agent start after restoring the snapshot.

Teardown workaround: depends on where the resources live:

  • If the resources are inside the VM like a local DB, they get destroyed with the VM, so no extra cleanup is needed.
  • If the resources are external like a cloud DB or an external service, you can start a long running process via terminals and use trap for termination signals:
#!/bin/bash
# start-db.sh
setup_db  # bring resources up
trap 'teardown_db' EXIT SIGTERM SIGINT
# keep the process alive
while true; do sleep 60; done

Important note: there’s no guarantee the Cloud Agent VM sends SIGTERM before stopping. The VM might just be killed without a graceful shutdown. Treat this as best effort, not a reliable mechanism. For critical external resources, a TTL or heartbeat pattern on the service side is the safer approach.

About Hooks: sessionStart, sessionEnd, and other hooks currently only work in the desktop Cursor IDE, not in Cloud Agents. This is on the team’s radar, no timeline yet, but your request helps with prioritization.

About Agent ID during install: there’s no documented way to access it at that stage. You can try inspecting environment variables env | sort inside your install script to see what’s available, but I wouldn’t count on it being exposed.

More on environment setup: Setup | Cursor Docs

Let me know how it goes.

4

Hi @deanrie,

Thanks for your answer. I’m gonna give a shot the solution you described.

I didn’t find an environment variable with agent id. I though there might be another way of getting the id. The idea here is to make a request to an external server to set up resources and assign them the agent id. Then the server would be periodically checking which agents are finished and tear down resources associated with such agents.

I’m gonna try with terminals and trap. Will keep you posted. Thanks!

5

Hey, yeah, the heartbeat/TTL pattern on the external server side is the most reliable approach. Exposing the agent ID as an env var isn’t supported yet, but it’s a good feature request.

Another option is to generate your own unique ID, for example with uuidgen, in the start script and send it to the external server. It won’t be tied to the agent ID, but it should work fine for tracking resources and cleaning them up.

Let me know how it goes with trap.

6

Hi @deanrie ,

I would also be interested with Cloud Agents hooks. I spent a lot of time testing stuff as this documentation indicates that they should work with Cloud Agents but no luck :

Did I misunderstand it or is the doc misleading ? (“repo hooks” = git hooks or Cursor session hooks ?)