Coordinator agent isn't able to handle sub agents he created in sub directories when its operating from the parent directory

[a4xrbj1]

Steps to reproduce

1. Have the following setup (similar to ecosystem around overstory) - a parent directory and repo's in sub directories
2. Launch overstory coordinator in the parent directly
3. Ask explicitly to run mulch prime which is filled with knowledge of his past failure to handle this parent/sub directory task
4. Coordinator spools lead agent in sub directory
5. Coordinator "forgets" about monitoring the lead agent and thus never merges the commits from the builder in the sub directory/worktree

NOTE:

Please note the "temporary" fix that I've added in the "Actual behavior" section

Expected behavior

Coordinator agent monitors progress and checks every 2 minutes

Actual behavior

Coordinator "forgets" about monitoring the lead agent and thus never merges the commits from the builder in the sub directory/worktree

---
  On the systemic problem: you're right, and it's a real failure. When I sling a lead in a subdirectory repo, the mail lands in that repo's mail system but I'm sitting at the
  workspace root checking a different one. I don't catch merge_ready until you manually prompt me.

  The fix is to use the /loop skill — have me poll mail on a recurring interval so I catch completions without you having to babysit me. Want me to set that up now, and if so,
  what interval (e.g. every 2 minutes)?

Yes
  ⎿  Async hook Stop completed

⏺ Skill(loop)
  ⎿  Successfully loaded skill
  ⎿  Async hook UserPromptSubmit completed

⏺ CronCreate(*/2 * * * *: check overstory mail across all repos and merge any merge_r…)
  ⎿  Scheduled d2825727 (Every 2 minutes)

⏺ Scheduled. Every 2 minutes I'll check mail across all repos and merge any merge_ready branches without waiting for you to prompt me.

  - Job ID: d2825727 — cancel with CronDelete if needed
  - Cron: */2 * * * *
  - Auto-expires: 3 days

This is the temporary fix but I think this sort of setup should run correctly right out of the box.

overstory version

0.8.6

Bun version

1.3.10

Operating system

macOS 26.3.1

[a4xrbj1]

UPDATE:

The temporary fix of running a "loop" cron job isn't working either.

It just stupidly goes into every subdirectory (despite no agent being spilled there by the coordinator) and checks. Even worse, when no agent is spilled at all (apart from the coordinator agent obviously) the coordinator also checks past merges again, and to make matters worse (and burn a lot of precious tokens), it checks if these need to be merged.

Would really appreciate if someone has an idea on how to have the coordinator agent run properly. This is a huge setback (for me personally) to an otherwise excellent ecosystem which previously worked very well, as long as it only had to run in a subdirectory and work on one repository only.

But it comes short and fails in monitoring/merging as soon as it operates out of the parent directly and/or has to handle a task across more than one repository.

[a4xrbj1]

UPDATE 2:

I've generated an insights report with /insights and it came up with a good suggestion:

Coordinator agent:

Now — the insights report. It's a fair read. The top recurring failure (wrong repo for agent dispatch) is something I have two explicit mulch failure
  records for and I still keep repeating it. The monitoring lapse you just had to call out is also consistent with the pattern it describes.

  The report's suggested quick win — a /dispatch skill with a pre-flight checklist — would genuinely address both. Want me to create that skill now? It would enforce: validate
  target sub-repo, sd create in the right directory, ov sling from there, and monitor proactively until merge_ready.

When to use it: Any time you want me to dispatch a lead agent to a sub-repo. Instead of just telling me what to do and hoping I get the repo right, you invoke the skill
  directly:

  /dispatch meteor-desktop fix loose equality comparisons in fixture files
  /dispatch test2 add tests for the GEDCOM import orphan detection logic
  /dispatch admin audit npm packages for outdated versions

  What it does differently from just telling me:

  The skill forces me through a structured checklist that I reliably skip when operating from plain instructions:
  1. Validates the repo exists before touching anything
  2. sd create inside the target repo — not at workspace root (my #1 failure)
  3. ov sling from inside the target repo — same problem
  4. Monitors every ~60 seconds without you asking — my #2 failure
  5. Merges immediately on merge_ready — my #3 failure
  6. Closes issue + cleans worktrees automatically

  The key difference: When you invoke /dispatch, the skill's <process> block is injected directly into my context as explicit steps I must follow in order. When you just
  describe a task in plain language, I'm relying on memory and judgment — which is where the repeated failures happen. The skill removes that judgment gap.

This new skill solved the problem but it would be nice if it's a standard/default behavior

[lucabarak]

Confirmed — this is a mail routing isolation issue. Each .overstory/ directory has its own mail.db, and the mail command resolves project root from process.cwd() via resolveProjectRoot(). When the coordinator runs at the parent and a lead runs in a sub-directory with its own .overstory/, they write to different mail databases. The coordinator never sees the lead's merge_ready because it's polling the wrong mail.db.

The orchestrator agent definition (agents/orchestrator.md) actually describes a --project <path> flag for exactly this scenario:

ov mail check --project <repo-path> --agent orchestrator
ov status --project <repo-path>

But this flag isn't implemented in the actual CLI — ov mail, ov status, and ov merge all resolve project root from cwd with no override option.

The fix would be implementing --project <path> as a root override on the core commands (mail, status, merge), plus having the coordinator track which sub-repos it dispatched leads to so it can poll all relevant mail.db files.

Related: #102 has the same root cause (dashboard can't see sub-directory agents — single-DB limitation).

Your /dispatch skill workaround is actually the right pattern mechanically — it forces explicit sub-repo targeting. The gap is that this should be built into the coordinator's monitoring loop rather than requiring a custom skill.

[jayminwest]

Thanks for the thorough report and workaround details. Confirming @lucabarak's analysis — this is a real implementation gap.

The --project <path> flag is declared as a global CLI option (src/index.ts:153) and documented in the orchestrator agent definition (agents/orchestrator.md), but it's never actually wired through. resolveProjectRoot() in config.ts and all downstream commands (mail, status, merge) ignore it and resolve from cwd instead.

The fix is plumbing --project through resolveProjectRoot() so that ov mail check --project <sub-repo>, ov status --project <sub-repo>, and ov merge --project <sub-repo> target the correct .overstory/ directory. Until then, your /dispatch skill approach (explicitly cd'ing into the sub-repo) is the right workaround.

Keeping this open — it's a real bug, not a usage issue.

[a4xrbj1]

UPDATE 3:

Issue 97 is probably caused by this (my guess).

NOTE: I'm not using the suggested --project <path> flag as @jayminwest suggested, I still rely on the /dispath skill which works perfectly fine. This should work even without using the --project <path> flag, as the coordinator itself calls it a "split-brain" problem.

With the new version there's a new problem. Here's my conversation with the coordinator agent which explains it in detail:

Me: "There is a problem with the dashboard of test2 - I could see the open task but no agent working was shown, only former agents with the state of "completed". What could be
the cause of this problem, is it in the way you communicate from the parent directory while the agents are in the test2 subdirectory?"

Coordinator:

Good question. Let me investigate the state locations.
There it is. Two separate .overstory/ state stores — one in workspace root, one in test2. They're running on different run IDs too:

• Workspace root (/workspace/.overstory/): run-2026-03-11T06-03-05-889Z — sees coordinator, 10 sessions
• test2 (/workspace/test2/.overstory/): run-2026-03-08T09-46-44-258Z — sees 55 sessions, 0 active agents

Your suspicion is correct. The issue is a split-brain between the two overstory state stores:

1. The coordinator runs from workspace root, so ov status from the coordinator's perspective reads workspace/.overstory/sessions.db — which only sees itself.
2. The lead and builder were slung with ov sling from the workspace root, but their worktrees live under test2/.overstory/worktrees/, and they register in
   test2/.overstory/sessions.db.
3. The dashboard in test2 reads from test2/.overstory/ — so it sees the seeds issue (from test2/.seeds/) but only sees agents registered in test2/.overstory/sessions.db. By
   the time you looked, the lead/builder had already completed and were showing as "completed" rather than "working".

The root cause: ov sling resolves the .overstory/ root based on the target repo's git root (test2), not the coordinator's working directory (workspace). So agent sessions get
written to test2/.overstory/sessions.db while the coordinator monitors workspace/.overstory/sessions.db. When I ran ov status during monitoring, it was reading from the
workspace root and somehow still saw the agents — likely because ov status walks down into sub-repos. But the dashboard UI may only read the local .overstory/.

This also explains why the earlier ov status output showed a different run ID (run-2026-03-08) than the coordinator's run (run-2026-03-11). The agents were joining an older
run context in test2/.

Likely fix direction: Either the dashboard needs to aggregate across nested .overstory/ stores, or ov sling should register agents in the coordinator's state store (the root
where the coordinator lives) in addition to/instead of the sub-repo's store.

[a4xrbj1]

The --project <path> flag is declared as a global CLI option (src/index.ts:153) and documented in the orchestrator agent definition (agents/orchestrator.md), but it's never actually wired through. resolveProjectRoot() in config.ts and all downstream commands (mail, status, merge) ignore it and resolve from cwd instead.

The fix is plumbing --project through resolveProjectRoot() so that ov mail check --project <sub-repo>, ov status --project <sub-repo>, and ov merge --project <sub-repo> target the correct .overstory/ directory. Until then, your /dispatch skill approach (explicitly cd'ing into the sub-repo) is the right workaround.

This is from the Coordinator as I'm still seeing issue with orphaned worktrees and also sqlite3 with leftover that the coordinator had to fix with ov clean -all in these subdirectories:

Key insight: The coordinator runs at workspace root and sees workspace-level .overstory/. But all real work happens in sub-repo .overstory/ instances. Every ov command (sling,
   mail, status, merge, clean) is cwd-sensitive — it reads the .overstory/ relative to where you run it. The --project flag exists on the top-level ov CLI but is not wired to
  subcommands (confirmed: ov clean --project fails, ov sling --project not available).

  This means the coordinator must cd into each sub-repo for every operation. The /dispatch skill already handles this correctly.

I've also asked the coordinator to asses the existing /dispatch skill and see how it can be improved and noted that its probably a process that we need to regularly run given the constant improvements/additions to the "overstory" npm package(s). Here's his feedback:

/dispatch skill assessment

  What it does well:
  - Correctly cds into the target repo for every command
  - Pre-flight validates the repo exists and has .overstory/
  - Creates seeds issues in the correct repo scope
  - Monitors proactively
  - Handles merge and cleanup

  Gaps I identified:

  1. No cleanup of stale state before dispatch. If a previous run left conflict entries in the merge queue or completed sessions, the dashboard shows phantom issues. The skill
  should run ov clean --sessions --mail --branches (targeted, not --all) before dispatching if stale state is detected.
  2. No post-merge cleanup step for worktree directories. ov worktree clean --completed only cleans worktrees with active session records. If sessions are wiped first (or the
  agent was stopped via dashboard), orphaned directories remain.
  3. No multi-repo batch awareness. When dispatching the same task to multiple repos (like the gitignore task that caused all these conflicts), there's no step to track which
  repos succeeded vs failed. The conflict entries across 7 repos were never retried or cleaned.
  4. No stale state detection in monitoring loop. If the lead is stopped via dashboard (external intervention), the monitoring loop has no guidance for detecting this and
  cleaning up.
  5. No guidance on mulch scoping. The skill says "Record mulch learnings on completion" in the dispatch body but doesn't specify that leads/builders must run mulch from within
  the sub-repo, not the workspace root.
  6. Missing STEP for events.db cleanup. Events accumulate across runs and are never purged. Over time (13,919 events currently across all repos), this grows unbounded.

Please take note on his findings, even though these are specific for my projects, I'm sure other will face the same or similar issues.

Instead of trying to fix them each with the help of Claude Code and our own willingness to spend time on it, these should be addressed at the repository itself IMO. Keen to hear what others think, especially @jayminwest and @lucabarak .