Whenever Cursor tried to create a recurring build it fails to connect to “enterprise.contribsys.com”.
Could you take a look at this issue? This makes using Cloud Agents (especially when automating things) quite annoying (and it also introduces subtle bugs)
Thanks in advance!
All the best,
Tales
Steps to Reproduce
Create a Rails project using sidekiq enterprise (likely not limitted to that, though)
Do a manual build, it should work
Leave it to create a recurring build. it will fail
Expected Behavior
Recurring builds to behave like manual builds
Operating System
Linux
Version Information
Cloud Agents (so Cursor’s own environment)
For AI issues: which model did you use?
For AI issues: add Request ID with privacy disabled
Hey @hey-tcione, thanks for the detailed report, and sorry for the trouble here.
We dug into this and found what is going on. Manual builds run with your personal network allowlist applied, but recurring builds run under your team’s identity, so they only get the team-level network allowlist plus the defaults. Since enterprise.contribsys.com is only on your personal allowlist, recurring builds cannot reach it while your manual builds can.
To unblock it right away, have a team admin add enterprise.contribsys.com (and any other domains your install step needs) to the team-level network allowlist in the Cursor dashboard (under Team Settings → Security & Identity → Network Access Control)
Thanks for the fast response! That makes it clear, thanks!
I don’t have access to the team allowlist (probably it is gated by the enterprise plan). This makes builds not viable for us. Is there a way to either have allowlists on our current plan or disable builds for specific projects?
Good point, things work a little differently for Team Plans. However, you shouldn’t be totally blocked.
While viewing an environment find the “Agent Network Access” section. Set the dropdown to “Defaults + Environment Allowlist”, then add enterprise.contribsys.com to the “Network Allowlist” box that appears (one domain per line), and save.
That option keeps the standard set of allowed domains (package registries and so on) and adds your entries on top, so prefer it over “Environment Allowlist Only”. This setting applies to every build of that environment, including the recurring ones. If your install step needs any other non-standard domains, add them to the same list.
Understood and thanks. We currently favor environment.json files to set up each env, and I couldn’t find the option in the schema . Should I stop using the file and use the setup form instead?
It should be possible via environment.json (the schema appears to be missing a few recent additions), but I’d like to confirm with the team that we’re ready to support this! Will let you know when I hear back.
Even better news: there’s an environment-level option that works on your current plan. In your repo’s .cursor/environment.json, add both of these keys:
