Automation runs ignore the secondary repo of a multi-repo cloud environment

[Pete_Thompson]

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

An automation that uses a multi-repo cloud environment gets a workspace with only the primary repo. The environment’s start scripts and terminals run, but the secondary repo is never cloned, and the run’s GitHub token can’t access it. The same environment launched through the API (POST /v1/agents) gets both repos.

Steps to Reproduce

1. Create a cloud environment with two repos: org/repo-a (primary) and org/repo-b.
2. Create an automation with a Slack “New message in channel” trigger. Set its environment to that environment.
3. Post a root message in the channel to trigger a run.
4. In the run, execute:
   pwd; ls ..; git -C ../repo-b remote -v; gh auth status; gh repo view org/repo-b

Actual output:

• pwd is /workspace, and repo-a is cloned directly there. ls .. lists /, so there is no sibling checkout.
• git -C ../repo-b … → fatal: cannot change to ‘../repo-b’: No such file or directory
• gh auth status shows a ghs_ installation token.
• gh repo view org/repo-b → GraphQL: Could not resolve to a Repository with the name ‘org/repo-b’
• All of the environment’s configured terminals started (tmux ls). So Cursor applied the environment’s setup but not its repo list.

The agent then told the user it couldn’t make the change because the repo wasn’t available.

Expected Behavior

The automation’s workspace matches the environment: both repos are cloned, and the run’s GitHub token can read and push to both. This is what happens when we launch the same environment with POST /v1/agents and env: { type: “cloud”, name: “” }.

Operating System

Linux

Version Information

N/A. The automation launched the agent. We viewed it in the web dashboard, not the IDE or CLI.

For AI issues: which model did you use?

Model name: Auto

For AI issues: add Request ID with privacy disabled

Request ID: f0cf2a02-2249-4cb3-bda7-c11da3dda08b
Background Agent ID: bc-99a8f05f-4bef-59f1-96f4-43bb8976db94

Additional Information

• Automation ID: a4445c67-7562-11f1-a8a0-cafc5ef88358
• Questions: Do automations support multi-repo environments? If they do, is there a per-automation repo setting that overrides the environment’s repo list?

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Colin]

Hey @Pete_Thompson, thanks for the report!

Automations do support multi-repo environments. When an environment is selected on the automation, its repo list is what the run uses. There is no separate per-automation repo setting that overrides it. When the automation only has a repository selected, the run uses that repository’s own single-repo environment. That’s why its setup and terminals ran, but the second repo was not cloned or included in the GitHub token.

Looking at the run you linked, it started before the automation was switched to the multi-repo environment (that change was saved ~50 minutes later), so it ran with only the primary repository. No new run has triggered since the change.

Could you try this and let us know?

1. Open the automation and confirm the repository / environment picker shows your multi-repo environment by name (not a single repository).
2. Post a new root message in the channel to trigger a fresh run.
3. In that run, execute:

pwd; ls /agent/repos; gh repo view org/repo-b

On a multi-repo run, both checkouts live side by side under /agent/repos. If you still only see one repo, reply with the new agent ID and roughly when you changed the environment on the automation, and we’ll dig in.

[Pete_Thompson]

Hi Colin,

The automation has the multi-repo environment selected. When I attempt to run a test I receive the error “You do not have access to a repository in the selected automation environment.” The Cursor GitHub app has both repos selected.

Can you suggest where I should look to resolve this?

[Pete_Thompson]

Okay, I got this working through creating a new automation. Not sure why it wasn’t working previously.

Closing as resolved, thank you for your help.