Cursor Web
Hi Cursor team,
I am look for how to manage Cursor Automations as Code or with API. As far as I know, we need to configure Cursor Automations on the web, though we can duplicate an Automation. It would be helpful to manage automations as code.
Hey, thanks for the feature request. Totally get the pain here. Managing automations only via the web UI is annoying when you want version control and reproducibility.
This isn’t a new request, it’s come up in a few threads already. Feel free to jump in with your use case or upvote to help boost the signal:
I can’t share a specific timeline for this yet, but there’s interest in it. If we have updates, we’ll post them.
@deanrie Thank you for sharing it.
I think this might become more and more important.
Navigating through a lot of automations, we currently have around 20 of them, and many more planned. Our use case is that we’re writing graphs (workflows), where delivery starts with an idea, then nodes in this graph avances the idea through specifications, then implementation planning, then implementation, then code review agents, QA check agents etc, until deploy.
What we have now is our own cooked CLI to be able to monitor executions by these automations (or as we call them, loops in the graph).
That’s why we’re interested in an API as top priority, but a COnfig-as-Code wouldn’t hurt either, for defining our graphs (workflows).
Hey @Ronnie_Kilsbo, that’s a great, concrete use case: a graph of ~20 automations with nodes from idea to deploy. This kind of setup is exactly where a web-only configuration hits its ceiling.
Re the API: there’s a dedicated thread for this, listing/starting/following automation agents via the API. It’d be great to share your scenario there, including monitoring executions, to help strengthen the signal:
And a couple threads closer to config-as-code and collaboration on shared automations that are also relevant:
There’s interest in this direction, but I can’t share a specific timeline yet. If we have an update, we’ll post it in the thread.
Lovely, thank you Dean.
What I will do is write a reply post there, being a bit more thorough what we’re humbly asking for, where they are absolute blockers and where they’re more nice to have’s.
Cheers.
Just to follow up - I was the one who posted the thread Dean was referring to, and that is now closed, because I deemed it a duplicate of this very thread.
This is top priority for us, so if that thread can be opened again if it’s truly separate from this discussion here that would be much appreciated
Ah, cheers Magnus.
I’ll await @deanrie’s response and see how I can help.
Hey, thanks for flagging this, both Magnus and Ronnie.
Agreed. The Automations API request list / start / follow-up automation agents is big enough to keep in a separate thread from config-as-code. That keeps the signal clean for each topic. I reopened 166898, so we can continue the API discussion there:
@Ronnie_Kilsbo, your setup a graph of about 20 automations and monitoring executions via your own CLI is exactly the kind of thing that’s worth writing up there in detail. What are the absolute blockers for you, and what’s nice to have. That’s the best way to boost the signal.
We’ll keep discussing config-as-code here and in related threads:
I can’t share a specific timeline yet, but there’s interest in this direction. If we have an update, we’ll post it in the threads.
Hey Magnus, given Dean’s response, would you be able to re-open your thread so I can add my message there? 
I’d appreciate it, thank you.
Hi Ronnie - Would love to, but doesn’t seem like I’m able to. Must be done on Cursor’s end AFAICT
Can you open that post? Really interested. in the Automations API, as it unlocks a lot of use-cases for us.
Examples of automations we have currently:
Particularly the last point - that would be a lot more useful if it was able to read automation prompts, read run logs, and update the prompt for the next runs.
Hey @nilsen and @Ronnie_Kilsbo, I reopened the Automations API thread Automations API, so feel free to write up detailed API use cases there. The cases from the latest post daily or weekly data aggregation, changelog generation, and especially a meta-agent that reads run logs and updates prompts for future runs are exactly what’s worth describing in detail. What are the absolute blockers for you, and what’s just nice to have? That’s the best way to boost the signal.
We’ll keep discussing config-as-code here and in the related threads:
For now, here’s what you can already use:
Listing automations themselves and exporting their run history via API isn’t available yet. That’s exactly the direction worth describing in detail in 166898. I can’t share a specific timeline, but there’s interest in it. If there’s an update, we’ll post it in those threads.
Thank you, I’ve now written a post there with our two main use cases and what API calls we’re missing for those.
Cheers.
