Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/tanchuping/codex-task-watchdog/codex-watchdognpx skills add TanChuping/codex-task-watchdog --skill codex-watchdoggit clone --depth 1 https://github.com/TanChuping/codex-task-watchdogWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tanchuping/codex-task-watchdog/codex-watchdog)<a href="https://agentmods.dev/skills/tanchuping/codex-task-watchdog/codex-watchdog"><img src="https://agentmods.dev/badge/skills/tanchuping/codex-task-watchdog/codex-watchdog.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00104 | $0.02218 |
| Opus 5 | $0.00052 | $0.01109 |
| Sonnet 5 | $0.00021 | $0.00444 |
| Haiku 4.5 | $0.00010 | $0.00222 |
Grade A, and why
codex-watchdog scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Codex Watchdog
Use scripts/codex_watchdog.py as the only state-changing interface. Resolve it from this skill's directory and invoke it by absolute path; do not rely on the current working directory.
Honor control requests
Treat these requests as executable controls, including in a brand-new conversation:
- On “关闭watchdog” or equivalent, run
python <WD_SCRIPT> disable, then report the returned state. - On “启用watchdog” or equivalent, run
python <WD_SCRIPT> enable, then report the returned state. - On a watchdog status request, run
python <WD_SCRIPT> status, then report the result. - On “卸载/彻底移除 watchdog”, run
disableand thenuninstall. Preserve the skill and incident files unless the user separately asks to delete them.
Do not merely acknowledge these requests. disable persists across conversations; while disabled, do not arm jobs unless the user enables monitoring again.
Monitor long work
For each tool or delegated worker expected to exceed 30 seconds:
- Check
statusonce before an immediately launched batch. If enabled, classify each attempt and have the main conversation choose a rolling no-progress threshold from references/timeout-policy.md. Runarm --kind KIND --turn auto --generation 1 --timeout-seconds CHOSEN-SECONDS --label SHORT-LABELfor every initial attempt. The script usesCODEX_THREAD_IDwhen available and otherwise keeps anunknown-threaddiagnostic label; tag UUIDs still isolate jobs. Retain the exact unique tag returned by the script. - Keep parallel work isolated: assign one tag to one attempt, and pass that exact tag to every later command.
- Observe the real worker or output at least every 30 seconds. The main conversation or a dedicated monitoring subagent may record a heartbeat after judging the attempt healthy from current evidence such as advancing scan counters, new stream/log/tool-call records, changing output files, active process work, worker phase changes, or other task-specific progress. A timer tick or an unchanged “thinking” label alone is not proof of progress.
- Treat expiry of the chosen interval as a mandatory review point, not an automatic stop. Inspect the exact attempt without preempting the main task. If current evidence shows normal progress, run
heartbeat TAG --note EVIDENCEand continue waiting. Absence-only evidence—including no completed command, unchanged files, no child process,post_tool_transition_unobserved,model_preparing_no_request, or a quiet model stream—never authorizes interruption. Stop only on explicit user instruction or positive terminal/failure evidence. A task may run much longer thantimeout_secondswhile it continues producing verified progress. Keep the separate 180-second hard limit for a single image-generation attempt when the active repository or user instructions require it. - Always run
disarm TAG --reason REASONimmediately on completion, failure, cancellation, or a confirmed abnormal stall. Use a new generation and a new tag for any retry.
What ships with it
8 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- agents/openai.yaml 278 B
- references/manifest.schema.json 2.7 KB
- references/protocol.md 9.7 KB
- references/recovery-manifest.schema.json 2.4 KB
- references/timeout-policy.md 3.5 KB
- scripts/check_thread_health.py 2.5 KB runs code
- scripts/codex_watchdog.py 71 KB runs code
- scripts/test_codex_watchdog.py 34 KB runs code
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 94 lines · 104 tokens per session scan A f8708328972d
codex-watchdog is a skill published in the GitHub repository TanChuping/codex-task-watchdog (2 stars, last pushed 1mo ago), licensed MIT. It adds 104 tokens to every session and 2,218 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
api-endpoints
Adding or changing API operations in @repo/operations. One source of truth (defineOperation + a Zod schema) becomes an HTTP endpoint, an OpenAPI operation, an MCP tool, TS + Python SDK methods, a latitude CLI command, and an in-process agent tool — descriptions and contracts must be written with all of these readers…
fix-datadog-issues
Find, triage, and fix production errors captured by Datadog Error Tracking, then open a PR. Use when asked to look at "Datadog issues/incidents/errors", "find and fix bugs from Datadog", investigate the most-frequent or newest production errors, or work a specific Datadog Error Tracking issue.
web-frontend
When to use: apps/web UI — routes, @repo/ui, TanStack Start server functions and collections, navigation (Link vs useNavigate), forms (useForm with createFormSubmitHandler + fieldErrorsAsStrings when Zod validation errors should appear on fields), Tailwind layout rules, design-system updates, and useEffect /…
database-postgres
Drizzle schema, repositories, RLS, SqlClient wiring, Postgres migrations, psql / reset, or platform mappers (toDomain / toInsertRow).
notifications
Multi-channel notifications. Adding a new notification kind, group, or channel; in-app + email delivery; per-user prefs; project-level gates; idempotency.
async-jobs-and-events
Queues and workers, domain event publishers, async notifications or projections, or not doing that work inside HTTP handlers.