Repository navigation
[bug] subordinate_status: refusals report success, lookups need a UUID the model doesn't have, and repo GitHub coordinates are missing #320
Description
Two small defects in the same tool, both visible four times in one Coder Lead conversation
(2026-08-06, 5fab318d).
1. A refusal is reported as success
lib/connectors/supervision.ts:121:
const subs = await subordinateSummaries(ctx, only);
if (!subs.length) {
return {
content: only ? "You do not supervise that agent. Call list_subordinates…" : NO_SUBORDINATES,
success: true, // ← a refusal
};
}So the transcript shows:
✅ subordinate_status You do not supervise that agent. Call list_subordinates to see who you may address.
A green tick on a call that did nothing. It appeared in four consecutive turns (22:33, 22:34,
22:35, 22:36), each time followed by a retry — so a reader scanning the tool log sees eight
successful status calls where there were four.
success is what the console renders and what the model reads back. A failed lookup should be
success: false, the same way check_work returns success: false for a run that is not yours.
2. It takes an instance id, and the model has a name
Every one of those four turns follows the same shape:
✅ subordinate_status You do not supervise that agent…
✅ list_subordinates [{ instanceId: "964594b6…", name: "FAS platform", … }]
✅ subordinate_status { … the real answer … }
The user says "Focus on FAS platform"; the model has a name; the tool wants a UUID. It costs
an extra round trip on every single turn, and the tool description already tells it to go read
list_subordinates — so the retry is the documented path, not a mistake.
Accept a name (or a unique prefix) and resolve it against the roster the tool already loads. The
graph is small and owner-scoped; there is no ambiguity risk worth this cost. Keep the id working.
3. Related: the Lead has no GitHub coordinates for its subordinates
Same conversation, 22:36:31 — user asks "Are there any open tickets?":
❌ github_list_issues Couldn't reach GitHub for "fws" (No github access for "fws".)
The Lead passed "fws", because that is what it has: subordinate_status reports the repo's
display name (fws/platform), never its githubRepo (freewebstore-online/platform). It then had
to ask the user for the owner/name — for a repo the platform already knows, since coding_repos
stores github_repo and the FAS diagnostics show it populated.
Include githubRepo in the per-subordinate repo block. Same class as #259: the supervisor was
missing a fact the platform holds, so it guessed and then asked the human.
Verification
- An unknown subordinate returns
success: false. subordinate_statusresolves "FAS platform" without a precedinglist_subordinates.- A Lead asked for open issues on a subordinate's repo reaches GitHub without asking the user for
the path.
Activity
serge-ivo commentedon Aug 6, 2026
Verified: GitHub access was never the problem
Called
github_list_issueson the FWS instance with the correct coordinates:The GitHub App is installed and working. The Lead's failure was entirely the owner string — it
passed
"fws", the display name, because that is allsubordinate_statusgives it (point 3 above).But the error text sent the user to fix the wrong thing
and the Lead concluded, reasonably:
Both halves of the message mislead:
Xis nota GitHub owner at all — no installation could ever match it. A user following this would go
re-authorize an App that is already correctly installed.
unknown owner fails identically, forever. The hint invites exactly the loop it should prevent.
Same shape as #271, where a 409 appended "(and run
pags up)" unconditionally and sent a userchasing a runner that was already up. An error that names the wrong remedy is worse than a terse
one, because it is actionable in the wrong direction.
Suggested
Distinguish the causes in
installationTokenForOwner's failure path:<owner>"<owner>is not a GitHub owner — did you mean<githubRepo>?"The platform knows the answer:
coding_repos.github_repoholds it.Once point 3 lands (ship
githubRepoinsubordinate_status) this particular call stops failing —but the misleading text stays reachable by any other caller with a bad owner, so it is worth fixing
on its own.
fix(supervision): a supervisor can read back the work it delegated, a…
serge-ivo commentedon Aug 6, 2026
Fixed in 792d7a0. All three.
1. Refusal reports success.
observeSubordinatesnow returnssuccess: falsefor a named agent that is not in the caller's graph. An empty roster deliberately stayssuccess: true— that is a true answer to "what is everyone doing", not a failed lookup. I checked the neighbouring tools: no other connector tool had the pattern (delegate_goal,check_delegation's run-id branch andcheck_workalready returnfalse).2. Lookups needed a UUID.
subordinate_status,check_delegationanddelegate_goalnow take a name ("FAS platform") or a unique fragment, via a shared pureresolveSubordinate:FASstays reachable next to a sibling namedFAS platform;delegateToInstancere-checks membership on the resolved id, so a looser spelling cannot widen who is reachable;resolved: {asked, instanceId, name}, because otherwise the answer silently redefines the question.3. GitHub coordinates.
repo.githubRepo(fromcoding_repos.github_repo) is in the per-subordinate repo block, and the legend says which of the two is a GitHub path — "repo.nameis a display label; it may look like a path and still not be one" — following theconnectivityprecedent from #259 of putting it in the payload, not only the description.pnpm -r typecheck,vitest(4389 passed),biome,docs:drift,check-file-size.fix(supervision,github): answer from the store that holds the answer (#…
fix(supervision): the roster fits, and the count rides in front of it…