Why was this a problem with Deno? Up until recently you had to use package.json and npm/pnpm for it to work, but even then it was better than Bun or Node since you could use import map to avoid compiling packages for testing etc (Node and Bun's type stripping doesn't work across local monorepo dependencies, and tsx produces mangled source maps making debugging a hassle). Now Deno has built-in workspace/monorepo support in deno.json.
Why is that? Seems like an agent framework limitation, not a reasonable requirement in general. (I do not have this limitation, but I also have a custom agent stack)
On my own machine I have a dev/ folder full of checkouts of other repos, and I'll often run Claude Code or Codex CLI in that top level folder and tell it to make changes to multiple projects at once. That works just fine.
(I was going to try claude again this weekend, but when I tried to login, got an error and am reminded how much down time I experience from Anthropic, arg...)
In other words, do Anthropic tools provide any affordances for this or is it something I have to manage externally?
That product only works against one GitHub repo at a time. The Claude Code you install and run locally doesn't have a GitHub attachment at all and can run against whatever you checkout yourself.
Here's an open feature request about it: https://github.com/anthropics/claude-code/issues/23627
In a poly repo setup, agents are less effective having to infer changes across repo boundaries using specs rather than code as context. Changes that impact multiple repos are also much messier to wrangle.
How do you minimally build based on the changeset? How do you know this is sufficient for correctness? What happens when feature branches get out of date and don't see the upstream change that breaks the local branch? How do you version subprojects, as they change or as a whole?
Monorepos have a habit of creating hidden dependencies. The languages you use can help or hurt here.