When OpenClaw spawns an agent shell with a different HOME than the user
that ran `gh auth login` (per-agent codex homes, systemd User= services,
sudo'd shells), `gh` looks at $XDG_CONFIG_HOME/gh or $HOME/.config/gh and
reports "not logged into any GitHub hosts" even though the operator HOME
has a valid hosts.yml.
Add `detectGhConfigDirMismatch` in src/agents/skills/gh-config-discovery.ts:
a pure helper that takes process env plus a fileExists probe and returns
either "auth-discoverable", "no-known-auth", "explicit-gh-config-dir-set",
or a "mismatch" with the alternate config dir, the host file path, and a
suggested GH_CONFIG_DIR value to set on the gateway service environment.
The helper checks `/root`, `$SUDO_USER`'s home, and `$USER`'s home as
candidate operator homes on Linux/macOS, and uses platform-specific path
joins so the same logic works on Windows test runners.
Wire the helper into the doctor skills health flow: when the github skill
is reported and the gh binary is present, call the discovery helper and,
on a mismatch, print a "GitHub CLI" note with the operator-actionable
fix instructions before any unavailable-skill repair prompt.
Update skills/github/SKILL.md with a troubleshooting subsection that
documents GH_CONFIG_DIR for service/agent environments where HOME differs
from the user that ran `gh auth login`.
Fixes#78063.
Summary:
- Mark forced/manual cron runs active in the task registry until completion and clear them in finally.
- Add regression coverage for manual run success and failure cleanup.
- Update changelog for #78243 and apply a small lint-only test fix needed after rebasing on latest main.
Fixes#78233
Verification:
- pnpm test src/plugin-sdk/channel-streaming.test.ts src/cron/active-jobs-manual-run.test.ts
- pnpm run lint:extensions:bundled
- pnpm test extensions/codex/src/app-server/side-question.test.ts
- CI: https://github.com/openclaw/openclaw/actions/runs/25673031776
Co-authored-by: Feelw00 <dhrtn1006@naver.com>
Regression: the drain IIFE finally (`drain.ts:263-271`) performed an
unconditional `FOLLOWUP_QUEUES.delete(key)` + `clearFollowupDrainCallback(key)`
using only the key, without checking whether the captured `queue` still matched
the map entry. Under the `/stop` + immediate followup sequence, a late-returning
D1 finally could delete the map entry for a fresh Q2 and orphan it until the
next enqueue.
Fix: only remove the map entry and drain callback when `FOLLOWUP_QUEUES.get(key)
=== queue`. Mirrors the identity pattern noted in
`subagent-announce-queue.ts:62-64`.
Adds `src/auto-reply/reply/queue/drain.identity-guard.test.ts` which uses real
`enqueueFollowupRun` / `scheduleFollowupDrain` / `clearSessionQueues` (no
module mocks) and a Deferred gate to park D1 inside `runFollowup`. The test
uses `restartIfIdle=false` on the Q2 enqueue so D1's finally is the only
mutator that can touch the map entry, producing deterministic pre/post-fix
differentiation:
pre-fix : get(key) === undefined (Q2 orphaned), depth === 0
post-fix : get(key) === Q2, depth === 1
AI-assisted (fully tested). 1082 auto-reply/reply tests pass, pnpm check +
pnpm build clean.
