fix: time out hung gh secret/variable list in dispatch

[SebTardif]

scripts/dispatch-jobs.mjs listRepoSecrets and listRepoVariables call spawnSync(gh ...) with no timeout. If gh secret list or gh variable list never returns, npm run dispatch pins until someone kills it.

What happens

1. Cross-repo dispatch runs the token-secret preflight and calls gh secret list --json name, then gh variable list --json name.
2. Those children used spawnSync with no timeout.
3. A stalled GitHub CLI never returns, so dispatch cannot skip the preflight or continue.

This is separate from dispatch child runCommand timeouts.

Proposed fix

Give those inspect children the same timeout contract as worker planner/review children:

• CLOWNFISH_DISPATCH_SECRET_LIST_TIMEOUT_MS (default 2 minutes)
• spawnSync(..., { timeout, killSignal: "SIGKILL" }) for gh secret list and gh variable list
• On ETIMEDOUT, keep the current skip-with-warning path (could not inspect repo secrets / could not inspect repo variables) and return null

A source contract plus hung-secret and hung-variable fixtures live in test/app-token-auth.test.mjs.

Fork branch

This repo limits pull requests to collaborators, so I could not open a PR. The patch is on my fork:

• Branch: SebTardif:fix/dispatch-secret-list-timeout
• Compare: main...SebTardif:fix/dispatch-secret-list-timeout
• Commit: 1fd1e42f

Feel free to cherry-pick that commit, or I can open a PR if you add this account as a collaborator.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 5, 2026, 12:59 AM ET / 04:59 UTC.

Summary
Current main still permits both authentication preflight children to hang indefinitely. This is a bounded, source-proven dispatch bug; the related issues address different subprocesses.

Reproducibility: yes. from source: cross-repository dispatch synchronously waits for either listing child without a deadline. A deliberately stalled gh fixture can establish the failing regression; this review did not execute it.

Next step
A focused repair can bound the two inspections without new configuration or changed auth policy; establish failing regressions and recheck live fix ownership before opening a PR.

Review details

Best possible solution:

Give both inspection children a shared finite deadline and forced termination while retaining their distinct existing warning and authentication outcomes.

Do we have a high-confidence way to reproduce the issue?

Yes, from source: cross-repository dispatch synchronously waits for either listing child without a deadline. A deliberately stalled gh fixture can establish the failing regression; this review did not execute it.

Is this the best way to solve the issue?

Yes to child-level deadlines using the existing failure branches. The proposed public timeout setting is optional and unnecessary for repairing the hang; variable-list failure must retain the existing App-auth checks.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 6309880aba75.

Label changes

Label justifications:

• P2: A stalled inspection can block an operator's dispatch process, with a narrow and source-proven repair boundary.
• impact:crash-loop: The reported impact is an indefinitely hung dispatch process requiring external termination.

Evidence reviewed

Acceptance criteria:

• node --test test/app-token-auth.test.mjs
• node --check scripts/dispatch-jobs.mjs
• npm test
• npm run validate
• git diff --check

What I checked:

• Verified current checkout: The origin remote identifies openclaw/clownfish, and HEAD matches the supplied fetched-main SHA. The working tree remained clean. (6309880aba75)
• Both synchronous inspections remain unbounded: The secret-list and variable-list spawnSync options contain cwd, encoding, and stdio but no timeout. Their warning/null branches are reached only after the child returns. (scripts/dispatch-jobs.mjs:478, 6309880aba75)
• Reachable trigger and existing failure semantics: Cross-repository cluster-worker dispatch invokes the inspections before backlog and capacity checks. Secret inspection failure skips the preflight; variable inspection failure continues through existing token/App checks and does not universally authorize dispatch. (scripts/dispatch-jobs.mjs:419, 6309880aba75)
• Existing regression harness: The App-token tests exercise dispatch through a fake gh executable, including successful secret and variable listing. This provides a focused location for separately wedged-child regressions; no tests were executed during this read-only review. (test/app-token-auth.test.mjs:48, 6309880aba75)
• Existing subprocess timeout pattern: Worker result review already uses spawnSync timeout, SIGKILL, and ETIMEDOUT handling. CHANGELOG.md records that worker-specific change under Unreleased; it does not cover these dispatch inspections, and no local release tags were listed. (scripts/run-worker.mjs:270, 6309880aba75)
• Related reports have separate repair boundaries: The supplied bodies for fix: time out hung dispatch child and publish-backlog spawn #324 and fix: time out hung gh exec in capacity wait #325 identify dispatch/backlog children and capacity polling respectively. Current source confirms those use separate spawn or execFileSync calls. (scripts/lib.mjs:162, 6309880aba75)

Likely related people:

• Vincent Koc: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.