Multi-repository tasks worked- until today

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

We built a Docker container with special instructions to support changes across multiple repositories, run code validation, and unit tests. It also installs required libraries. We provided our own authentication via SSH to GitHub. We are using agent worker start and host the agent as a “machine” with access to multiple git repositories at once.

Everything worked and now today the agent won’t even try to do any work…

Environment error
Agent encountered an error
Repository URL is required for worker connections
You can retry by writing a follow-up below.

Please stop assuming the agent task only applies to a single repository! This development flow works perfectly, but it is failing because changes to the agent harness on your side.

Steps to Reproduce

Start a machine agent outside the context of a GitHub repository and any request reports an error claiming it’s confused- even though it should be able to do the task perfectly fine. The agent harness is causing it to fail… not the model itself.

Expected Behavior

The agent is supposed to read AGENTS.md and know exactly everything it needs to know to accomplish the task. The wrapper around the agent shouldn’t assume the task only applies to a single repository.

Operating System

Linux

Version Information

Doesn’t matter because the agent harness is stopping it from attempting to do the work.

For AI issues: which model did you use?

Doesn’t matter because the agent harness is stopping it from attempting to do the work.

For AI issues: add Request ID with privacy disabled

Request ID: bc-92ac760b-0ce9-4efd-9e48-2929a3f153d6

Does this stop you from using Cursor

Yes - Cursor is unusable

5

We created a repository with a .gitignore that contains a wildcard: * and embedded it into the Docker container’s main /workspacefolder.

This satisfied the assumptions that everything is working in a single repository… and now the agent works again. But this just seems very silly. Our main limitation right now is that we cannot create PRs because the PR MCP tool embedded into the harness is said to be the highest priority tool, so instead it creates /compare/ URLs for GitHub.

7

Same issue from my end, this was working fine a few days back. Seems to be broken since “Remote Control” got released

9

Same issue from my end, completely blocks agent usage in my case

11

Hey @david.newmon and thanks @Antony_Fuentes1 and @DanielS for the extra reports.

First, this is on us, not your setup. A recent change to the self-hosted worker path made machine-worker agents require a registered repository, so a flow that started fine before now hits Repository URL is required for worker connections. We’ve identified the cause and a fix is already in progress.

To unblock right now, the worker just needs a real repo identity (which is exactly what your .gitignore * trick gives it). The cleaner, supported way is to register your actual repo roots when you start the worker:

agent worker \
--worker-dir /workspace/repoA \
--worker-dir /workspace/repoB \
start
  • Multi-repo on one worker is fully supported: --worker-dir is repeatable (up to 20 roots) and every root is exposed to the agent.
  • The first --worker-dir is the assignment identity, so point it at a real git checkout with a valid origin. That satisfies the requirement without the dummy repo.
  • Roots with valid git origins register their routing metadata automatically. You can confirm all roots were picked up by starting with --verbose and checking the workspace paths / repository URLs.

Fully repo-less machine agents (no repo at all) aren’t supported yet, but that’s actively being built.

On the PR point in your follow-up: the /compare/ URL fallback is a separate limitation with how machine workers open PRs. Would you mind starting a new thread for that one so the right folks can track it properly?

Let me know if the --worker-dir approach gets you unblocked.

12

Thanks for the fast reply!

We will look into the --work-dirCLI and see if that is a net benefit to us.

The GitHub MCP claimed it was the highest priority tool, so we couldn’t get the gh CLI to execute. Not sure it would have even authenticated. Seemed like there was confusion around how to create a PR when attempting to manage multi-repository workflows in general.

I don’t remember the specifics, but we ultimately gave up and updated our AGENTS.md to include these instructions:

## PR Creation

- Don't use the `ManagePullRequest` because it is not going to work.
- Present a GitHub link to create the PR such as: https://github.com/[org]/[repository]/compare/[branch-name]

Background / Implementation Details

For the curious, here’s a high-level outline of our implementation:

Each docker container copies all of our repositories into their own ephemeral copy of the repositories when the container starts (so we can run multiple agents in parallel across multiple repositories). It doesn’t scale very high, I think the limit is 5 agent workers per user. But it scales high enough for our current development flows.

We also segmented the main environment so we have different sets of repos along with AGENTS.md files, and skills for each type of agent. For example, a “platform” agent has access to a shared Python library, and the main web app. Our “models” agent has access to the same shared Python library and several AI model repositories and helps work on integrations.

We also can freely inform the agents to clone other repos not already included in the base set to perform less common tasks but still have full code traceability to accomplish most tasks.

The main repo has sub-folders for each type, and gitignores for all of the sub-repositories:

  • models
    • AGENTS.md
    • .cursor/skills …
    • repo-1
    • repo-2
  • platform
    • AGENTS.md
    • .cursor/skills …
    • repo-1
    • repo-2

The docker image is built with:

  • Common tools: git, node, aws, ripgrep, etc…
  • A python virtual environment at /pyenvwith a few common tools like ruff

When the container is started the sub-folder is mounted read-only to /code. When it starts, it copies /code into /workspace (which is the working directory). Installs any dependencies in-place and starts the agent. We also setup the agent to run as a non-root user within Docker.

This setup works pretty well. Allows us to build skills, special agent instructions for various tasks, setup after-hours automations, etc.