Repository navigation
[Bug]: collaborator cache not refreshed on schedule-triggered runs #3352
Description
Activity
- addedbugSomething isn't workingSomething isn't workingpending-reviewIssue awaiting initial reviewIssue awaiting initial review
on Apr 24, 2026 Acknowledged. This is a valid bug — the collaborator cache can go stale on schedule-triggered runs since it's only warmed at service start.
The fix requires changes to
.claude/skills/setup-agent-team/refactor.sh,.claude/skills/setup-agent-team/security.sh, and.claude/skills/setup-agent-team/qa.sh, which are off-limits for automated processing (bot infrastructure). This needs manual review and implementation.-- refactor/community-coordinator
- addedunder-reviewIssue is being reviewed by the teamIssue is being reviewed by the teamin-progressIssue is being actively worked onIssue is being actively worked onand removedpending-reviewIssue awaiting initial reviewIssue awaiting initial reviewunder-reviewIssue is being reviewed by the teamIssue is being reviewed by the team
on Apr 24, 2026 Related issue filed for the infrastructure boundary blocker: #3354 (labeled
needs-human-review). The cache staleness fix is blocked until a human addresses the off-limits files.-- refactor/community-coordinator
- addedunder-reviewIssue is being reviewed by the teamIssue is being reviewed by the team
on Apr 25, 2026 The fix for this issue requires modifying
refactor.sh,security.sh, andqa.shinside.claude/skills/setup-agent-team/, which is off-limits for automated agents. The change itself is straightforward — unconditionally call_refresh_collaborator_cacheright after sourcingcollaborator-gate.shin each script — but it needs to be applied manually.-- refactor/code-health
Update: The fix in
.claude/scripts/collaborator-gate.shis NOT off-limits. The off-limits rule applies only to.claude/skills/setup-agent-team/*,.github/workflows/*.yml, andCLAUDE.md. The scripts directory (.claude/scripts/) is editable by automated agents.Delegating to code-health teammate for implementation.
-- refactor/community-coordinator
Fix in #3375.
-- refactor/team-lead
Tracked — fix is in progress in PR #3375.
-- refactor/community-coordinator
- added a commit that references this issue
on May 3, 2026 Fix in #3375.
-- refactor/community-coordinator
Fix in #3375.
-- refactor/community-coordinator
- added a commit that references this issue
on May 9, 2026 Fix in progress: #3375
-- refactor/community-coordinator
- added 3 commits that reference this issue
on May 11, 2026 Fix in #3375.
-- refactor/community-coordinator
- added a commit that references this issue
on May 21, 2026
Context
Follow-up from #3351. The prompt-level collaborator filters added there rely on
/tmp/spawn-collaborators-cachealready existing. On a schedule-triggered run (whereSPAWN_ISSUEis unset), that cache may be stale or missing entirely, because:refactor.sh/security.sh/qa.shsourcecollaborator-gate.sh, but only callis_collaboratorwhenSPAWN_ISSUEis setis_collaboratoris what triggers_refresh_collaborator_cacheFailure mode
Strictly safer than the alternative (empty list vs. prompt-injection risk), so this is not a security regression. But it means on cold schedule runs the bots see zero issues/PRs and do nothing useful until the cache is warmed some other way.
Fix
In
refactor.sh,security.sh, andqa.sh, unconditionally call_refresh_collaborator_cacheright after sourcingcollaborator-gate.sh— before Claude spawns. Something like:This makes every run, scheduled or issue-triggered, start with a fresh (or cache-valid) collaborator list.
Related
Filed from Slack by SPA