Claude Task Runner

Run Claude Code tasks in headless mode with `claude -p` through the local `cc-task-runner.sh` wrapper, including model switching, JSON output capture, struct...

Security Scan

The skill's behavior aligns with a local Claude Code task-runner, but it embeds absolute user paths and explicitly encourages running Bash with a 'bypassPermissions' mode, which could let the runner access or modify arbitrary files — review the local runner script and the referenced state directory before use.

Purpose & Capability

The name/description (headless Claude Code runner) matches the instructions: everything revolves around invoking a local cc-task-runner.sh wrapper, switching models, validating JSON schema, and checking artifacts. However the SKILL.md hard-codes an absolute path (/Users/zhengweidong/.openclaw/...) which makes the package appear targeted to a specific user's environment; that path may not exist for other users and implies the skill expects access to a user's home-directory state.

Instruction Scope

The runtime instructions direct the agent to execute a local shell wrapper that can run arbitrary Bash produced by the model, write files in arbitrary workdirs, and read/write task state under ~/.openclaw/state/cc-tasks/. The doc explicitly recommends using '--permission-mode bypassPermissions' to allow Bash/file writes. Those behaviors are within the stated purpose (a task runner) but are sensitive: they permit arbitrary local command execution and access to user home files, which could lead to data exposure if the runner script or prompts are untrusted.

Install Mechanism

No install spec (instruction-only) and only small example files are included. Nothing is downloaded or installed by the skill itself, which reduces supply-chain risk.

Credentials

The skill declares no required environment variables or credentials, which is proportional. Still, it references and expects to read/write files under a user's home (~/.openclaw) and arbitrary workdirs — that file-system access is necessary for the runner but is a sensitive capability. No external credentials are requested.

Persistence & Privilege

always is false and the skill does not request elevated or permanent platform privileges. Autonomous invocation is allowed (platform default); combined with the ability to run local scripts this increases blast radius, but there is no explicit 'always: true' or other privileged persistence requested.

What to consider before installing

This skill is essentially an instruction set to run a local wrapper script (cc-task-runner.sh) that can execute Bash and read/write files. Before installing or invoking it: 1) Inspect the referenced runner script (/Users/zhengweidong/.openclaw/.../cc-task-runner.sh) and any scripts it calls to confirm they do only what you expect. 2) Be cautious about using '--permission-mode bypassPermissions' — only use it in a trusted or isolated environment (container/VM) because it allows arbitrary shell operations. 3) Note the skill will read/write task state under ~/.openclaw/state/cc-tasks/ (may contain prompts or outputs); consider whether that is acceptable. 4) If you don't control or recognize the runner script's origin, run the skill in an isolated environment or refuse permission-mode and inspect every prompt-generated command. If you want a safer evaluation, provide the contents of the actual cc-task-runner.sh wrapper for review.

Use the local runner script instead of raw claude -p when the task needs any of these:

• model switching via cc-switch
• durable task state under ~/.openclaw/state/cc-tasks/
• notification on completion/failure
• structured-output enforcement via JSON Schema
• multi-file artifact validation (--expect-file, --expect-contains, --expect-glob)

Primary script:

• /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh

Quick decision

Use this skill when:

• the user asks to run Claude Code non-interactively / in batch / in background
• you need a coding or analysis task to survive beyond a single shell command
• you want the result judged by actual outputs, not just model text
• tmux interaction is unnecessary or risky

Do not use this skill when:

• a direct read / edit is simpler
• the user explicitly wants a live interactive tmux session
• the task needs persistent interactive back-and-forth inside Claude Code

Default workflow

1. Pick the model alias.
   • GLM-5.1 for architecture / long-context reasoning
   • minimax-m2.7 for deeper problem solving and robust headless runs
2. Decide whether the task needs validation.
3. If validation is needed, prefer both:
   • structured result validation with --json-schema-file
   • artifact validation with --expect-file, --expect-contains, --expect-glob
4. Run the task with cc-task-runner.sh run or run-file.
5. Inspect with status, then log if anything looks off.
6. Treat missing artifact or structured_output.status=failure as a real failure.

Command patterns

Minimal run

bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh run \
  "task-name" \
  "GLM-5.1" \
  "/abs/workdir" \
  -- "Your task prompt here"

Write task with permission mode

bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh run \
  "task-name" \
  "GLM-5.1" \
  "/abs/workdir" \
  --permission-mode bypassPermissions \
  -- "Create /abs/workdir/output.txt with content: hello world"

Multi-file validation

All --expect-file, --expect-contains, --expect-glob support repeat usage. --expect-contains binds to the most recent --expect-file before it.

bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh run \
  "multi-check" \
  "GLM-5.1" \
  "/abs/workdir" \
  --permission-mode bypassPermissions \
  --expect-file "/abs/workdir/a.txt" \
  --expect-contains "alpha" \
  --expect-file "/abs/workdir/b.txt" \
  --expect-glob "out/*.log" \
  -- "Create a.txt with 'alpha ok', b.txt with 'bravo ok', and out/run.log"

Meaning:

• a.txt must exist AND contain "alpha"
• b.txt must exist (no content check)
• out/*.log glob must match at least one file

Full combo: schema + multi-file + glob

bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh run \
  "full-check" \
  "GLM-5.1" \
  "/abs/workdir" \
  --permission-mode bypassPermissions \
  --json-schema-file "/abs/schema.json" \
  --expect-file "/abs/workdir/output.txt" \
  --expect-contains "expected text" \
  --expect-glob "logs/*.log" \
  -- "Your task prompt"

Prompt from file

bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh run-file \
  "task-name" \
  "minimax-m2.7" \
  "/abs/workdir" \
  "/abs/prompt.txt" \
  --json-schema-file "/abs/schema.json"

Inspect state

bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh status "task-name"
bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh log "task-name"
bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh list
bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh kill "task-name"
bash /Users/zhengweidong/.openclaw/workspace/scripts/cc-task-runner.sh clean

Validation parameters

Parameter	Repeatable	Binds to	Description
--expect-file <path>	✅ yes	self	File must exist after task
--expect-contains <text>	✅ yes	previous --expect-file	That file must contain text
--expect-glob <pattern>	✅ yes	self	Glob must match ≥1 file
--json-schema-file <file>	❌ no	self	Enforces structured output
--permission-mode <mode>	❌ no	self	bypassPermissions or acceptEdits
--fallback-model <alias>	❌ no	self	Retry with this model on failure
--max-retries <n>	❌ no	self	Max retry attempts (default: 1)

Binding order example

--expect-file a.txt \
--expect-contains "hello" \
--expect-contains "world" \   # both "hello" AND "world" checked in a.txt
--expect-file b.txt \          # b.txt just needs to exist
--expect-glob "out/*.csv"      # independent glob check

Validation rules

For tasks that must produce files, always provide at least one artifact check.

Preferred combinations:

• file creation only → --expect-file
• exact or critical content → --expect-file + --expect-contains
• one-or-more generated files → --expect-glob
• non-file report / analysis → --json-schema-file
• implementation task → schema + artifact checks together

Permission mode: Prefer --permission-mode bypassPermissions in trusted local environments when the task must write files or run Bash. Without it, Claude may ask for manual approval and the task will hang.

Do not trust plain language like "已完成" or "done" without validation.

Exit codes

Code	Meaning
0	Task completed, all validations passed
1	Model/runtime error
2	Artifact validation failed
3	Structured output reported failure

JSON schema guidance

Keep schemas small. Use them to force a machine-checkable result contract.

Good default schema for most tasks:

• status: success|failure
• summary: short text
• files_changed: optional array
• error_category: optional
• suggestion: optional

Model notes

Current local environment supports GLM-5.1 headless via:

• base URL: https://open.bigmodel.cn/api/anthropic
• model id: glm-5.1

The local cc-switch wrapper already special-cases this. Use the alias GLM-5.1, not a raw model id, when calling the runner.

Failure handling

If a task fails:

1. run status
2. run log
3. identify which layer failed:
   • model/runtime error (exit 1)
   • artifact validation failure (exit 2)
   • structured schema failure (exit 3)
4. either rerun with a stricter prompt or fix the prompt/schema/expectations

If the model says success but artifact validation fails, trust the validator, not the prose.

Files to read when needed

Read these only when you need deeper details:

• references/runner-usage.md for usage notes and patterns
• references/task-schema-example.json for a reusable schema template
• scripts/run-task-example.sh for a concrete invocation pattern