Git PR trigger hides Automations multi-repo dropdown (cron workaround)

Support Bug Reports
, ,
1

### Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

When editing a Cursor Automation, the top repository / environment dropdown (the control that lets you give the agent access to multiple repos) is missing if the only triggers are Git pull-request events such as Pull request opened.

This happens in both the browser Automations dashboard and the Cursor desktop app. Same automation, same missing dropdown in both places.

The dropdown appears if I add a cron trigger. I can then select multiple repositories. If I remove the cron trigger, the dropdown disappears again.

I have automations that need to run on PR opened and still access a second related repository. Docs say source-control triggers can connect to one repository or a multi-repo environment, but the editor hides the picker entirely for Git PR-only automations.

This is not the trigger card’s “select repo” control (which repos fire the automation). It is the top dropdown that controls which repos the agent can access / which environment is used.

Steps to Reproduce

  1. Open an existing automation or create a new one. Reproduce in the browser dashboard and again from the Cursor app.
  2. Set the only trigger(s) to Git events, e.g. Pull request opened. Do not add a cron trigger.
  3. Look at the top of the editor for the repository / environment dropdown used to give the agent access to multiple repos.
  4. Observe that the dropdown is not shown in either surface. The header instead says something like Repository from Git Trigger.
  5. Add a cron trigger.
  6. Observe that the top dropdown now appears and multi-repo selection works.
  7. Remove the cron trigger.
  8. Observe that the dropdown disappears again.

Expected Behavior

With a Git PR trigger only, the top repository / environment dropdown should still be visible (browser and Cursor app) so I can attach a multi-repo environment. The agent should be able to clone / access those extra repos when a PR event fires. Cron should not be required as a workaround.

Operating System

MacOS

Version Information

Reproduced on macOS in both:

  • Browser: Automations editor on the website
  • Cursor desktop app: Automations editor in the app

For AI issues: which model did you use?

Composer 2.5 (on the automation runs below)

For AI issues: add Request ID with privacy disabled

Cursor staff: Cloud Agent run IDs from a Git-PR-only automation that needed a second related repo. Happy to share more privately if needed.

  1. Environment error (best example)
    bc-2e5e5e99-d31e-4b21-8c21-e869239bfefd
    https://cursor.com/agents/bc-2e5e5e99-d31e-4b21-8c21-e869239bfefd
    PR opened, Aug 5 2026. Environment shown as second-repo +1. UI: Environment error. Agent encountered an error.

  2. Agent failed to start (no bc- id minted)
    Same automation, PR pushed, Aug 5 2026. Run summary: The background agent could not be launched. Verify the prompt, target repository, and branch configuration are valid.

  3. GitHub API 404 on the second repo (run completed anyway)
    bc-1ab82f1e-6273-4e75-9db9-92b0d9dde28a
    bc-7df545f4-50e6-4a8b-b8c0-b61653f07d55
    bc-7517a40c-169d-4fff-952f-d8e4acd900e6

Additional Information

Workaround: add a dummy cron trigger so the dropdown appears, select multiple repos / a multi-repo environment. Removing cron hides the dropdown again.

Related forum threads (titles only, new-user link limit): Multi-repo Automations not saving repo selection; Cloud Automation multiple git.

Docs (cloud-agent automations page) say source control triggers can connect to one repository or a multi-repo environment.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report with steps and the run ID. That really helps.

Confirmed, the docs are right about intent. Source control triggers should be able to attach a multi-repo environment, and the backend supports it. The fact that the top dropdown disappears when you use a Git PR only trigger is not expected behavior, and it’s not something in your setup. I shared this with the team and we’re tracking it. I can’t share a timeline yet, but I’ll reply in the thread when there’s an update.

For now, the cron trigger workaround is the only way to access the picker and select a multi-repo environment. One important warning though: when you remove the last non-git trigger, meaning the dummy cron, it doesn’t just hide the dropdown, it also wipes the saved environment selection. So after you delete the cron, you’ll need to pick the repos again. I’d recommend keeping the cron trigger in place, for example with a schedule far in the future, so the selection doesn’t get lost.

About the failing runs, Environment error, 404 on the second repo, agent could not be launched, the run IDs from Aug 5 are already outside the log retention window, so I can’t pull details for those. If these errors happen again after you set up multi-repo via the workaround, send fresh run IDs or a Request ID and we can look separately. The 404 on the second repo might not be related to the dropdown issue.

Let me know how it goes with the workaround.