repositoryDependencies in .cursor/environment.json not cloned when launching from the Repository environment

Support Help
,
1

Environment

  • Repository: humblFINANCE/humblWORKSPACE (private)
  • Environment: humblFINANCE/humblWORKSPACE, scope “Repository”
  • Config file: .cursor/environment.json, committed on main
  • GitHub App installation for the humblFINANCE org: repository access set to “All repositories” (confirmed, not a permissions issue)

.cursor/environment.json (relevant excerpt)

{
  "name": "humbl-fullstack",
  "repositoryDependencies": [
    "humblFINANCE/humblDATA",
    "humblFINANCE/humblAPI",
    "humblFINANCE/humblFINANCE",
    "humblFINANCE/openbbAPI"
  ]
}

Expected behavior
Launching a Cloud Agent against the humblFINANCE/humblWORKSPACE Repository environment should clone humblWORKSPACE plus all four repos listed in repositoryDependencies as siblings on disk, per the documented behavior (“Cursor clones each selected repo into the agent machine”).

Actual behavior
Only the primary repo (humblWORKSPACE) is cloned, at /workspace. None of the four repositoryDependencies repos are cloned - not even the two public repos (humblDATA, humblAPI), which rules out a per-repo permission failure. The install hook (which requires the sibling repos) then fails since it can’t find them.

Steps to reproduce

  1. Commit a .cursor/environment.json to a repo with a non-empty repositoryDependencies array (org/repo format, mix of public and private repos).
  2. Confirm the GitHub App installation for the org has “All repositories” access.
  3. Start a new Cloud Agent from that repo’s Repository environment.
  4. Inspect the agent’s filesystem - only the primary repo is present; none of repositoryDependencies are cloned.

Additional context

  • A separately configured Personal-scoped environment (manually grouping the same 5 repos) does successfully clone and boot the full stack, so this appears specific to how the Repository-scoped environment resolves repositoryDependencies, not a general GitHub access problem. But then I cannot control the op via code, and it nests under the first repo in the sidebar not the name of the workspace…
  • Org-level GitHub App access is confirmed as “All repositories,” so this is not a repo-authorization issue on our end.
5

Hey, thanks for the detailed report. This isn’t a bug, it’s a mismatch with what repositoryDependencies actually does.

repositoryDependencies does not clone extra repos. It only expands the GitHub token scope that gets passed into the environment so your own install/start scripts (or git submodules) can clone what they need. There is no automatic checkout of sibling repos from it, so you only see the primary repo. That’s expected behavior, and the same topic was covered here: Using cloud agents with environment.json

The doc line “Cursor clones each selected repo” refers to the multi-repo environment flow, when you select multiple repos while setting up the environment (that’s what you have working as your “Personal” env). That feature is what clones all selected repos as siblings, not repositoryDependencies.

Two options for your case:

  • Keep the multi-repo environment (your working “Personal” setup) if you need automatic checkout of all 5 repos.
  • Keep using environment.json, but clone the dependent repos yourself in the install script using the token. Also:
    • Entries must be github.com/org/repo, not org/repo. The bare format without a host gets filtered out and won’t be added to the token scope.
    • Entries must be on the same git provider and host as the primary repo.

Example:

{
    "install": "git clone https://github.com/humblFINANCE/humblDATA.git ../humblDATA && ...",
    "repositoryDependencies": ["github.com/humblFINANCE/humblDATA"]
}

On not being able to set up multi-repo checkout fully via a committed environment.json without the dashboard flow, fair point. I’ll pass it along as a request. I can’t promise an ETA. Let me know if anything doesn’t work with the install script.

6

I have also noticed that when using this setup, the agent cannot open a PR against a repoDependency, which I would have assumed the token was scoped for.

This is what the agent said.

The humblFINANCE-side fix is pushed to cursor/fix-humblchannel-client-side-api-url-5992 but I couldn’t open its PR — ManagePullRequest is scoped to this agent’s primary repo (humblWORKSPACE) only. Please open it manually: https://github.com/humblFINANCE/humblFINANCE/pull/new/cursor/fix-humblchannel-client-side-api-url-5992 (or ask a humblFINANCE-scoped agent to do so).

Will I need to scope a token from the organization for all the repos so it can use `gh` to manage all of that? What is the suggested way to get a sensitive var into the cloud environment managed via code? I can take a look, but would appreciate any insight if you have a tried-and-true method. It seems as though the only supported way as of now is manually in the secrets tab on Cursor Web?

7

…and there should be merge behavior too, but agent is blocking it:

I don’t actually have a way to merge PRs — my only PR tool (ManagePullRequest) supports create_pr/update_pr but has no merge action, and the gh CLI available to me is restricted to read-only use (I can view things but can’t run gh pr merge or similar write operations). So I can’t push the “merge” button myself here, even though you’ve explicitly asked.

Here’s the actual state of both repos so you (or someone with merge rights) can do it directly:

humblWORKSPACE

  • PR #10 cursor/fix-sibling-repo-clone-path-5992 → develop is open, mergeable, no conflicts — but it’s still a draft, so it needs “Ready for review” clicked before it can merge.
  • develop is only 3 commits ahead of main right now (PR #9’s merge), so once #10 lands, a develop → main PR would be a clean, small release.

humblFINANCE

  • Branch cursor/fix-humblchannel-client-side-api-url-5992 is pushed with the commit, but I never got a PR opened for it (cross-repo limitation noted last time — ManagePullRequest only works against this agent’s primary repo, humblWORKSPACE). You’ll need to open it manually: https://github.com/humblFINANCE/humblFINANCE/pull/new/cursor/fix-humblchannel-client-side-api-url-5992
  • develop and main are currently identical (0 commits apart), so once that PR merges to develop, a develop → main PR there would contain just this one fix.

If you want, I can:

  1. Mark PR #10 as ready for review isn’t possible via my tooling either (no draft-toggle on update_pr) — you’d need to click that in the GitHub UI.
  2. Once you (or someone) merges #10 into develop, I can open the follow-up develop → main PR for humblWORKSPACE for you to merge.
  3. If you’d prefer, I can also update the humblFINANCE PR body/title once it’s created via the link above, if you paste it back to me or give me merge/write access another way.

Let me know how you’d like to proceed — happy to prep the develop → main PRs once the feature branches are merged, but the actual merge clicks need to happen on your end or with a tool that has write access.

NEXT MESSAGE

Let me double check whether there’s a merge-capable tool I might have missed.

I hear you, but I’ve checked again and I genuinely don’t have a tool that can merge a PR:

  • ManagePullRequest (my only PR tool) only supports two actions: create_pr and update_pr — there’s no merge_pr action in its schema.
  • The gh CLI is available to me, but I’m explicitly restricted to read-only use with it (view PRs, logs, etc.) — I’m instructed not to use it for write operations like gh pr merge, and that’s a hard constraint I can’t override regardless of how the request is phrased.
  • I checked for any GitHub-related MCP server that might expose a merge tool — none is connected to this environment.

So this isn’t me declining as a policy choice on merging specifically — I literally have no mechanism available to execute the merge action itself.

What I can do:

  • If your Cursor setup has a GitHub MCP server you can enable (Settings → MCP), and it exposes a merge tool, I can use that once it’s connected.
  • Otherwise, the merges need to happen through the GitHub UI (or gh CLI run by you, since your own credentials would have write access) using the links I gave: PR #10 (mark ready, then merge into develop), then a develop→main PR for humblWORKSPACE; and for humblFINANCE, open the PR from cursor/fix-humblchannel-client-side-api-url-5992 first, merge into develop, then develop→main.

If you’d like, I can prep the develop→main PRs for both repos right now (as drafts) so they’re ready the moment the feature PRs land, and you’d only need to click merge three or four times total instead of also creating PRs. Want me to do that?

8

It seems repositoryDependencies in .cursor/environment.json expands the token for clone/read; it doesn’t grant PR write on those repos. IS that correct?

9

Yeah, almost, but let me clarify because there are two different mechanisms here.

About the token and PR write. repositoryDependencies expands the scope of the GitHub token that gets passed into the environment so your scripts and git can clone and read those repos. Whether the token has write access depends on the permissions you gave the Cursor GitHub App on those repos, read vs read-write. But the key point is different. The agent’s built-in PR tool ManagePullRequest always works only against the agent’s primary repo humblWORKSPACE, no matter what the token scope is. So you can’t open a PR to humblFINANCE from the same agent using the built-in tooling. That’s a cross-repo limitation, not a write permission issue.

About merging. The built-in PR tool doesn’t have a merge action at all, and the gh CLI in the cloud agent is read-only. So merging is done either in the GitHub UI, or by you via gh with your own permissions, or via a GitHub MCP server with a write token Settings → MCP if you want to give the agent merge capability. The agent isn’t making this up, it’s accurately describing its limits.

If you want the agent to open a PR to humblFINANCE, the option is to run an agent where the primary repo is humblFINANCE or use a separate agent per repo.

About secrets via code. Committing secrets into environment.json is intentionally not supported. Options are:

  • Interactive run from the UI, use the Secrets tab on the Cloud Agents dashboard, values are encrypted. This is the managed path.
  • Programmatic run via SDK or API, pass envVars TS or env_vars Python in CloudAgentOptions. They are encrypted and deleted together with the agent, and names can’t start with CURSOR_. Example: Dashboard settings | Cursor Docs

So via code means SDK or API launch with envVars, not committing a secret into the repo.

Let me know if any of this doesn’t match your setup.