claude-code (Deprecated alias)

Trigger Claude Code development tasks in observable tmux sessions with stable startup, progress visibility, and completion callback to OpenClaw. Use when use...

Security Scan

The skill's scripts largely match its advertised tmux-based Claude Code orchestration purpose, but metadata omits required tooling and the runtime instructions contain network/proxy and callback behaviors (claude --dangerously-skip-permissions, local proxy env, openclaw wake/call) that deserve careful review before use.

Purpose & Capability

The SKILL.md describes orchestrating Claude Code in tmux and the included scripts implement that. However the registry metadata claims no required binaries or credentials while the scripts explicitly require/expect many tools (tmux, claude, rg, python3, git, jq, ssh/scp, openclaw CLI). That mismatch (metadata says 'none' but the code needs many tools) is incoherent and should be clarified.

Instruction Scope

Runtime instructions and scripts legitimately read workspace files, run git status/diff, capture tmux panes, and require reading/writing completion reports under /tmp — all consistent with delivering an observable task. Notable runtime behaviors: they run 'claude --dangerously-skip-permissions', set https_proxy/http_proxy/all_proxy to localhost for the launched claude process, and call the OpenClaw CLI (openclaw gateway call wake / openclaw gateway wake) to deliver wake callbacks. These behaviors mean transcripts/reports and possibly pasted prompt contents can be transmitted outwards (to the OpenClaw gateway or via whatever proxy is listening).

Install Mechanism

There is no external install spec (no network download/install), which lowers install-time risk. However the skill includes executable scripts that will run on the host when invoked; users should treat these as code they must review. The package does not attempt to fetch archives from unknown URLs.

Credentials

The skill declares no required env vars/credentials but the scripts implicitly depend on the OpenClaw CLI, the 'claude' binary, and SSH access to remote hosts (scp/ssh to MINI_HOST/SSH_HOST). The start script also forces export of proxy env vars (127.0.0.1:6152/6153) for the claude process, which can redirect network traffic through a local proxy — a potential exfiltration vector if a proxy is present. Asking for SSH/scp access and invoking external CLIs is plausible for this purpose but the lack of explicit declarations in metadata is disproportionate and increases risk if users assume no external access is needed.

Persistence & Privilege

The skill does not request 'always: true' and does not modify other skills or global agent configuration. It writes small state files into its own state/ directory and writes completion reports into /tmp; these are expected for the stated workflow. It will rely on any existing SSH keys/agent for remote operations but does not escalate privileges itself.

What to consider before installing

This package is a tmux-based orchestrator and the scripts do implement that, but three practical concerns before installing/running it: 1) Metadata omission — the package does not declare required binaries but the scripts require tmux, the 'claude' CLI (run with --dangerously-skip-permissions), rg, python3, git, jq, ssh/scp and the OpenClaw CLI. Ensure you have and trust these binaries. 2) Data flow — the workflow captures tmux transcripts, workspace diffs, and writes JSON/MD reports in /tmp and uses the OpenClaw CLI to send wake callbacks; if you use the example 'openclaw gateway call summarize-tasks' you will be sending transcripts/reports to OpenClaw. Review whether that is acceptable for your data. 3) Proxy & network routing — start script force-sets https/http/all_proxy to localhost:6152/6153 for the claude process; confirm you control any local proxy to avoid unexpected network routing. Recommended actions: manually review the scripts (especially start-tmux-task.sh, wake.sh, and any remote scp/ssh targets), run scripts/bootstrap.sh --dry-run to check for missing tools, avoid running as root, and only run against projects/hosts you trust. If the maintainer can update the registry metadata to list required binaries/CLIs and document the proxy behavior, that would reduce risk and increase confidence.

Claude Code Orchestrator (tmux-first)

Use tmux-based orchestration for long coding tasks to avoid silent hangs and make progress observable.

Standard workflow

1. Create prompt file (avoid long shell quote issues).
2. Start a dedicated tmux session.
3. Launch claude --dangerously-skip-permissions in interactive mode.
4. Paste prompt into Claude.
5. Require callback command in prompt (via wrapper): bash {baseDir}/scripts/wake.sh "..." now
6. Share socket/session attach command with user.
7. On completion, review diff + lint/build + risk summary.

Start command

bash {baseDir}/scripts/start-tmux-task.sh \
  --label "gallery-detail-polish" \
  --workdir "/Users/yaxuan/.openclaw/workspace/work/active/02-gallery-ops" \
  --prompt-file "/Users/yaxuan/Downloads/gallery-website-design-system.md" \
  --task "参考这个修改我当前的画廊官网，注意优先打磨细节和质感，对整体结构展示先不用大改。"

Monitor commands

# attach
bash {baseDir}/scripts/monitor-tmux-task.sh --attach --session <session>

# capture last 200 lines
bash {baseDir}/scripts/monitor-tmux-task.sh --session <session> --lines 200

Task overview

List all running cc-* tasks at a glance — useful for "butler-style" summaries.

# Human-readable one-liner per task
bash {baseDir}/scripts/list-tasks.sh

# Structured JSON array (pipe to jq, feed to OpenClaw, etc.)
bash {baseDir}/scripts/list-tasks.sh --json | jq .

Options:

• --lines <n> — number of trailing pane lines to capture per task (default 20).
• --socket <path> — tmux socket path (default $TMPDIR/clawdbot-tmux-sockets/clawdbot.sock).
• --json — emit JSON array instead of human table.
• --target ssh --ssh-host <alias> — list sessions on a remote host.

Each entry contains: label, session, status, sessionAlive, reportExists, reportJsonPath, lastLines, updatedAt.

Combine with OpenClaw to generate a periodic butler summary:

# In an OpenClaw prompt / cron:
bash {baseDir}/scripts/list-tasks.sh --json | \
  openclaw gateway call summarize-tasks --stdin

Rules

• Prefer interactive Claude in tmux for visibility (not long claude -p one-shot for large tasks).
• Always include callback via wrapper bash {baseDir}/scripts/wake.sh "..." now in prompt.
• Startup script now uses robust submit (ready-check + multi-Enter retry + execution-state detection) to avoid "prompt pasted but not submitted".
• If no pane output for >2-3 min, inspect and restart session.
• Kill stale Claude processes before restart.
• Always return: session name + attach command + current status.

Status check (zero-token)

If wake not received within expected time, check task status before consuming tokens:

bash {baseDir}/scripts/status-tmux-task.sh --label <label>

Output: STATUS=running|likely_done|stuck|idle|dead|done_session_ended

• likely_done / done_session_ended → proceed to completion loop
• running → wait
• stuck → inspect (attach or capture-pane)
• dead → session lost, run complete-tmux-task.sh fallback
• idle → Claude may be waiting for input, inspect

Completion loop (mandatory)

When wake event "Claude Code done (...)" arrives, complete this loop immediately:

1. Acknowledge user within 60s: "已收到完成信号，正在评估改动".
2. Preferred path: read completion report generated by Claude Code task:
   • /tmp/cc-<label>-completion-report.json
3. If report missing, run local fallback immediately:
   • bash {baseDir}/scripts/complete-tmux-task.sh --label <label> --workdir <workdir>
4. Mandatory deep-read: read full JSON/MD report before replying.
5. Read context before replying:
   • Read completion report file(s) (/tmp/cc-<label>-completion-report.json/.md)
   • Read recent tmux transcript (monitor script) to capture what Claude actually did/failed/tried
   • Incorporate the latest user constraints from current chat
6. Then provide assistant analysis (not a fixed template):
   • what was actually completed
   • what is reliable vs uncertain
   • key risks/tradeoffs in the user's context
   • concrete next-step options
7. Ask explicit decision from user if scope drift exists.

Do not stop at wake-only notification. Wake is trigger, not final delivery.

Anti-pattern to avoid

• Forbidden: one-line fixed reply after wake without reading transcript + report.
• Forbidden: only relaying "done + report path" without analysis in user context.
• Forbidden: rigid templated output that ignores current conversation context.

Hard guardrails added

• Prompt now enforces “no wake without report”:
  • task must write /tmp/cc-<label>-completion-report.json + .md
  • final wake must include report=<json_path>
• Recovery command exists for deterministic fallback:
  • scripts/complete-tmux-task.sh reproduces evidence and emits structured report
• Delivery SLA remains mandatory:
  • wake received -> ack <= 60s -> report