ClawQueue – Open-source GitHub issue dispatcher for human-agent teams

ClawQueue (CQ) is a local human-agent workflow engine for GitHub.

Powered by OpenClaw for context-rich intake and, when configured, agent execution, CQ turns project context and operator intent into durable GitHub issues, then dispatches local workers to execute, report, and improve the work through reviewable GitHub history.

CQ is intentionally small: GitHub holds the durable work contract, OpenClaw helps shape the work, your machine runs the workers, and policy stays in markdown/config you can edit while using it.

CQ works in two very practical modes:

operate your own company/project with your own profile, agents, boards, and worklogcontribute to an external/open-source project through your fork by creating a project-specific CQ profile from the upstream repo’s README/docs/contribution rules, then routing issue-driven agent work into reviewed PRs

Warning

CQ is a trusted local operator tool. It shells out to local CLIs, starts agent processes, and expects the operator to control the machine, GitHub token, project boards, and notification channel.

Question	Short answer
What is it?
A local control loop that turns project context and human intent into GitHub issues, agent execution, artifacts, and PR-ready outcomes
Where does work live?
GitHub issues, boards, labels, comments, artifacts, and review history
Where does context live?
In OpenClaw/profile workspaces, markdown policy, local config, and issue history
What runs work?
CQ’s local scheduler launches the configured backend: OpenClaw agents by default/full-harness, or Claude Code/Codex direct CLI runners
Who is it for?
A trusted operator or small team that wants GitHub-native agent work without a hosted PM layer
What is it not?
A SaaS workflow product, public bot, secure multi-tenant executor, or fake “AI company OS”

Use CQ when you want:

• human ideas and project context to become durable, reviewable GitHub work
• GitHub Projects to remain the visible queue and review surface
• local execution with operator-controlled secrets, approvals, and context
• profile-specific agents/modes without forking the core workflow
• a system that is easy to inspect, patch, and reshape while it is running
• a structured local workflow for contributing features/fixes to an external or open-source GitHub project through your fork
• OpenClaw to amplify rough operator intent into scoped issues, then CQ to carry those issues through execution and review

Use CQ with OpenClaw to absorb your project mission, docs, priorities, and current discussion into scoped GitHub work, then run your own agent team against your repos, boards, profiles, and worklog. This is the default operating model for internal product, growth, ops, research, and review work.

Use CQ as a local contribution pipeline for a repo you want to improve. OpenClaw reads the upstream project context; CQ makes the resulting work durable, queued, executable, and reviewable:

• fork the target repo
• create a project-specific CQ profile from the upstream README, docs, roadmap, and contribution rules
• shape desired work into GitHub issues on your fork
• let CQ dispatch local agent work against that project context
• review the result and open a PR upstream

This gives you a durable GitHub-native agent workflow even when you do not “own the company” behind the repo.

Use OpenClaw to sharpen messy ideas, project goals, and half-formed feature requests into scoped issues; use CQ to route the work to specialist agents and keep artifacts/review history in GitHub instead of leaving everything trapped in chat.

Start with the docs, especially Getting started and the operator workflow.

Tip

Using OpenClaw? Give your OpenClaw assistant docs/guide/operator-workflow.md and say: “Install ClawQueue for this repo/profile, then explain back how the CQ process works before enabling automation.” That file is the best handoff document for a new OpenClaw installation because it covers the operating model, GitHub queue, agent routing, manual test run, and scheduler install.

flowchart LR
    A[Project docs + repo context] --> B[OpenClaw intake]
    C[Operator idea / request] --> B
    B --> D[Scoped GitHub issue]
    D --> E[GitHub Project queue]
    E --> F[CQ local scheduler]
    F --> G{Labels + profile policy}
    G --> H[OpenClaw agent]
    G --> I[Claude Code CLI]
    G --> J[Codex CLI]
    H --> K[Issue comment + artifact/PR]
    I --> K
    J --> K
    K --> L{Code/config/docs change?}
    L -->|cq:change| M[Review lane]
    M --> N[reviewer agent]
    N --> O[Human acceptance in GitHub]
    L -->|artifact/report| O

In this model, the human operator can ask OpenClaw for help in plain language; OpenClaw uses project context to shape that rough intent into a full GitHub issue, and ClawQueue provides the GitHub-native queue, scheduler, policy, and reporting loop that carries the issue through execution and review.

The intended operating loop is:

• OpenClaw reads the relevant project context, current conversation, and operator intent.
• A person or chief-of-staff assistant turns that messy intent into a scoped GitHub issue.
• GitHub Issues/Projects provide the shared queue, audit trail, and output history.
• CQ scans eligible issues, resolves labels into agent modes, moves board status, and starts one worker.
• The worker runs through OpenClaw, Claude Code ( claude

), or Codex (codex

) and reports back with an artifact, code change, or PR-ready result. - For cq:change

work, CQ moves the completed issue to Review where thereviewer

agent or a human checks the result before acceptance.

For multiple people, each person should run their own CQ/OpenClaw instance against the same GitHub boards, with their own accounts, secrets, approvals, and local context. By default CQ only dispatches Todo

items. A deployment can opt into other dispatch statuses in its profile policy, but Review is usually a human/operator lane.

Human-agent work gets safer and easier to improve when intent, execution, and review are separated cleanly.

OpenClaw is good at understanding messy conversation, project context, and operator goals. GitHub is good at durable issues, boards, comments, PRs, and review history. CQ connects those two worlds with a small local control loop: shape the idea, queue the issue, dispatch the agent, preserve the result, review the outcome.

If OpenClaw, Claude Code, Codex, or a local machine breaks, times out, or changes, the work contract still lives in GitHub: issue text, labels, board state, comments, artifacts, and review history.

That makes CQ useful for operator-shaped teams and solo contributors who want agent-amplified GitHub work without burying their company workflow or open-source contribution process inside one chat, one PM surface, or one vendor runtime.

CQ overlaps with several agent-workflow tools, but it makes a different bet: keep GitHub as the durable workflow surface and keep the human-agent loop local, small, and operator-shaped.

System	Main strength	CQ difference
Project-board tasks can launch isolated autonomous implementation runs	CQ focuses earlier and around the run: intake, profile policy, label routing, local context, and durable GitHub review history
A broader AI-company control plane	CQ is narrower on purpose: GitHub holds the durable work contract; OpenClaw shapes intent upstream; CQ carries issues through local execution and review
A dedicated PM surface for human+agent teams	CQ avoids adding another PM layer; issues, boards, labels, and comments stay repo-native
A coding-centric workflow stack	CQ is less runtime- and task-specific: it can route non-coding work and does not require one workflow surface

The practical difference is resilience and operator control. Policy lives in markdown, routing lives in config, private IDs stay local, work lives in GitHub, and the operator can evolve the system without rebuilding a platform around it.

In one line: CQ is the GitHub-native control loop for human-agent work: understand the project, shape the idea, create the issue, dispatch the agent, and review the result without letting the work disappear into the runtime.

CQ core should stay generic. Company-specific mission, agent souls, routing, and deployment settings should live in a profile folder or private deployment repo. See the profiles guide.

Recommended shape:

profiles/<company-or-team>/
  COMPANY.md
  agents/
  modes/
  config/
  secrets/   # ignored/private by default

This keeps CQ easy to upgrade while private company context can evolve in its own git history.

Generated reports and research artifacts should not be mixed into product/profile PR branches. CQ defaults to ignored local artifacts under .clawqueue/boards

; companies that want artifact history in git should use a second repo dedicated to worklog/artifacts. See the artifacts guide.

CQ works with the default GitHub Project status flow out of the box: Todo

, In Progress

, Done

, with dispatch defaulting to Todo

only. Teams that want a richer human-agent workflow can extend the board manually in the GitHub UI with statuses such as Inbox

, Review

, and Blocked

. When Review

is included in a project's dispatch_statuses

, completed cq:change

work moves to Review, the reviewer

agent can pick it up, and a passing reviewer result with extra_review_required=false

moves the item to Done. Bootstrap a new GitHub Project board with python3 scripts/bootstrap_project_board.py

.

The scripts/scheduler.py

entry point delegates to a small package:

Layer	Module	Responsibility
Operator status	scripts/status.py
Show active worker, recent decisions, attempt counts, and queued issues
Profiles/roadmap	profiles/ + GitHub issues/projects
Keep company/team identity separate from CQ core and track public work as issues
Workflow policy/config	clawqueue.config + config/company_workflow_policy.md
Load repo-owned routing rules, ignored private overrides, and env vars
Tracker/project board client	clawqueue.tracker
Read GitHub issues, cache ProjectV2 board state, move status columns, assign/unassign issues
Dispatcher/workflow engine	clawqueue.dispatcher
Sweep stale work, enforce locks/throttles/attempt limits, pick tasks, dispatch workers
Agent runner	clawqueue.runner
Build mode prompts and launch agents via openclaw , claude (Claude Code CLI), or codex
Notification/activity	clawqueue.notifications , clawqueue.activity
Optional Telegram ask flow, best-effort completion notices, and local session activity checks

Run the scheduler from cron, launchd, or another local scheduler:

python3 scripts/scheduler.py

On macOS, keep the repo in a non-privacy-protected path such as ~/ClawQueue

; cron may be denied access to ~/Documents

or ~/Desktop

.

OpenClaw (chief of staff) — reads project docs, repo context, and human intent
  → drafts structured GitHub issues
  → human reviews and publishes issue to the queue

GitHub issue in Todo
  → scheduler entrypoint scans configured repos/projects
  → dispatcher picks an eligible issue
  → labels resolve to a mode and agent
  → issue is assigned and moved to In Progress
  → runner starts the selected backend:
      openclaw  →  openclaw agent --agent <name>
      claudecode →  claude -p <prompt> --print
      codex      →  codex -p <prompt>
  → worker comments completion  <!-- clawqueue:done -->
  → CQ moves completed cq:change work to Review where configured
  → reviewer agent or human reviews the result
  → passing reviewer result (extra_review_required=false) moves Review → Done
  → failed/blocked review stays visible for retry or human action

ClawQueue decides which issue gets picked, which policy applies, and which backend launches it. OpenClaw is usually upstream as the context-rich intake/chief-of-staff layer; when using the openclaw

backend, it is also the runtime that launches the named specialist agent. With claudecode

or codex

, CQ passes the full task prompt directly to that CLI instead.

An issue is eligible when it is open, unassigned, on a configured board status listed in that project’s dispatch_statuses policy, under the attempt cap, and not blocked by locks, throttles, activity gates, or quota guards. The default policy is

Todo

only.Recommended convention: open + Review means “ready for reviewer/human review”; closed + Done means “accepted/final.” If a deployment wants Review to remain human-only, leave Review out of dispatch_statuses

.

CQ uses both persistent agents and mode prompts:

Agents are durable role specialists, especially when using the OpenClaw backend. A profile can define agents such asceo

,cto

, andcmo

, each with its own identity, soul, workspace, and memory.Modes are task lenses. They frame how a task should be approached and are injected into worker prompts. Modes are especially important for directclaude

orcodex

runner calls, which should be treated as mostly stateless unless that runner provides its own session layer.Issues are the shared memory of work. CQ should not rely on one chat transcript or one agent's private memory to know what happened.

Recommended operating model: the main assistant acts as chief of staff for intake and synthesis, using project context to improve rough human ideas before they become issues; CQ dispatches those issues to persistent profile agents for execution; modes frame each task; issue comments and profile memory preserve the outcome.

Six named agents cover the full company operating surface:

Label	Agent	Default model	Mode prompt	Scope
ceo
CEO
gpt-5.5 (Codex)

cto

CTOmodes/cto.mddev

/ engineer

Devcmo

CMOmodes/cmo.mdresearcher

Researchermodes/researcher.mdreviewer

Reviewer*(optional)*modes/reviewer.mdPriority order: ceo › cto › reviewer › cmo › researcher › dev › engineer

• No mode label → routes to cto

complex

label → escalates toceo

• All agents write a retrieval note to memory/notes/

after each task

Issue labels select the operating mode. Labels choose the cognitive mode; config resolves that role to one or more concrete OpenClaw agents. Board status decides whether the issue is ready.

Profiles should keep shared policy generic (ceo

, cto

, cmo

, etc.) and map those roles to local runtime agent ids with routing.agent_roles

, for example "cmo": ["manobot-cmo", "stratobot-cmo"]

. CQ picks the first configured candidate. If an issue needs a specific runtime agent, add a label like agent:manobot-cmo

to override role resolution directly for that issue.

Growth / marketing task

Title: Draft a campaign brief for a new data product
Labels: cmo, marketing

Objective:
Draft a campaign brief for a clearly defined customer segment.

Acceptance criteria:
- Define audience and value proposition
- Draft campaign message
- Suggest 3 channels
- Include success metrics
- Mark external copy as draft-only

Routes to the CMO agent via modes/cmo.md

.

Research / data task

Title: Evaluate data quality for a customer-facing report
Labels: researcher, data-research

Objective:
Compare a sample dataset against credible references and summarize quality risks.

Acceptance criteria:
- Identify comparison sources
- Explain method, assumptions, and units where relevant
- Report uncertainty, limitations, and quality concerns
- Recommend the next validation step

Routes to the Researcher agent via modes/researcher.md

.

Engineering task

Title: Add an active-worker status command
Labels: engineer, engineering

Objective:
Show the current active issue, repo, PID, and start time from local state.

Acceptance criteria:
- Handles missing or corrupt state
- Compile check passes
- No unrelated refactor

Routes to the Dev agent.

CQ is board-name agnostic. A deployment can define any ProjectV2 boards in its profile/config; the scheduler only needs the project number, ProjectV2 IDs, status field ID, and status option IDs.

A vanilla setup usually starts with 2-4 boards like these:

Example board key	Example title	Purpose
CORE
Core Taskboard	CQ operations, orchestration, bugs, documentation, and scheduler work
GROWTH
Growth / GTM	Sales, marketing, campaigns, partnerships, social, and conversion work
PRODUCT
Product / Engineering	Product planning, implementation, architecture, technical debt, and review
DATA
Data / Research	Research, analytics, data quality, reports, experiments, and evidence gathering

Keep these as examples, not CQ defaults. Real company board keys, titles, repo mappings, and ProjectV2 IDs belong in profiles/<company-or-team>/config/workflow_policy.md

, ignored private config, or environment overrides.

ClawQueue supports three execution backends. Set runner_backend

in the policy file or CLAWQUEUE_RUNNER_BACKEND

env var.

Backend	Value	Command	Auth needed	Best for
OpenClaw	openclaw (default)
openclaw agent --agent <name> --deliver ...
OpenClaw configured on PATH	Full OpenClaw harness: memory, delivery, multi-step agents
Claude Code CLI	claudecode
claude -p <prompt> --print --output-format text
Local claude CLI auth; may be API-key based or subscription/session based depending on the operator setup
Direct Claude execution when the operator has explicitly configured and approved that CLI use
Codex CLI	codex
codex -p <prompt>
Local codex CLI auth; may be OpenAI API-key based or subscription/session based depending on the installed CLI/account
Direct Codex/OpenAI execution; often useful for implementation and code-heavy tasks

When using claudecode

or codex

, the runner builds a full task prompt (including the mode instructions and acceptance criteria) and passes it directly to the CLI. OpenClaw is not involved at runtime — it is only needed upstream, as the chief of staff that drafts the issues.

Caution

Direct CLI backends inherit whatever account, subscription, API key, local session, quota, and terms apply to that CLI. Do not assume a personal subscription is allowed for automated/background use. In particular, be cautious with subscription-backed Claude/Claude Code sessions and check the relevant Anthropic/OpenAI terms and your organization’s policy before running CQ unattended against those backends. For production or team automation, prefer explicitly configured service/API credentials and clear spend/quota controls.

CLAWQUEUE_RUNNER_BACKEND=claudecode python3 scripts/scheduler.py

CLAWQUEUE_RUNNER_BACKEND=codex python3 scripts/scheduler.py

Minimal path:

• Install/configure OpenClaw if using the openclaw

runner backend. - Clone CQ.

• Configure workflow policy in config/company_workflow_policy.md

. - Put private IDs/secrets in config/clawqueue.private.json

or environment variables. - Test manually:

python3 scripts/status.py --no-queue
python3 scripts/scheduler.py

• Install the scheduler, preferably launchd on macOS:

python3 scripts/install_launchd.py --repo "$HOME/ClawQueue" --policy config/company_workflow_policy.md

Environment variables are escape hatches for local overrides. They are not the primary config mechanism for a single company instance.

Config loads in this order — later layers override earlier ones:

config/company_workflow_policy.md                    ← tracked generic default
profiles/<profile>/config/workflow_policy.md         ← tracked/shared profile policy when --profile is used
config/clawqueue.private.json                        ← gitignored generic private config
profiles/<profile>/config/clawqueue.private.json     ← gitignored per-user profile overrides
CLAWQUEUE_* env vars                                 ← rare one-off overrides
cp config/clawqueue.private.example.json config/clawqueue.private.json

cp profiles/<profile>/config/clawqueue.private.example.json \
  profiles/<profile>/config/clawqueue.private.json
python3 scripts/status.py --profile <profile>
python3 scripts/install_launchd.py --repo "$HOME/ClawQueue" --profile <profile>

For multiple schedulers on one Mac, give each LaunchAgent its own label and wrapper name. The installer now writes per-label runtime isolation by default:

python3 scripts/install_launchd.py \
  --repo "$HOME/ClawQueue" \
  --profile weatherxm \
  --label com.clawqueue.weatherxm \
  --wrapper-name clawqueue-weatherxm.sh

Defaults are ~/.openclaw/tmp/clawqueue/<label>

for CLAWQUEUE_STATE_DIR

, ~/.local/share/clawqueue/<label>

for CLAWQUEUE_LOG_DIR

, and the active profile/policy config directory for CLAWQUEUE_PRIVATE_CONFIG_FILE

. Override them explicitly with --state-dir

, --log-dir

, and --private-config

when a deployment needs fixed paths.

gh

authenticated with access to configured repos and ProjectV2 boards- Real repo names in private config or CLAWQUEUE_PRIMARY_REPO

/CLAWQUEUE_EXTRA_REPOS

• Real ProjectV2 IDs and status option IDs for board status updates
• For openclaw

backend:openclaw

on PATH (or setCLAWQUEUE_OPENCLAW_COMMAND

), and OpenClaw agents configured forceo

,cto

,dev

,cmo

,researcher

,reviewer

• For claudecode

backend:claude

CLI on PATH with an auth method explicitly approved for this CQ use case; API-key and subscription/session-backed setups have different policy and quota implications - For codex

backend:codex

CLI on PATH with an auth method explicitly approved for this CQ use case; API-key and subscription/session-backed setups have different policy and quota implications - Python available locally. Docs target Python 3.11+, but CQ may still run on older macOS system Python if your installed feature set is compatible; verify with the compile/test commands below.

Telegram, activity gates, quota tuning, mode URL overrides, and fallback maps are optional.

Variable	Used by	Purpose
CLAWQUEUE_POLICY_FILE
config	Override tracked policy file path
CLAWQUEUE_PRIVATE_CONFIG_FILE
config	Override ignored private config path
CLAWQUEUE_PRIMARY_REPO
tracker	Primary issue repo, e.g. owner/clawqueue
CLAWQUEUE_EXTRA_REPOS
tracker	Comma-separated extra repos to scan
CLAWQUEUE_PROJECTS_JSON
tracker	JSON override for project IDs, field IDs, status options
CLAWQUEUE_GITHUB_ASSIGNEE
tracker	GitHub login to assign while a worker is active
CLAWQUEUE_STATE_DIR
dispatcher	Runtime state dir; defaults under system temp
CLAWQUEUE_LOG_DIR
dispatcher	Decision/log data dir; launchd installer defaults to a per-label directory under ~/.local/share/clawqueue
CLAWQUEUE_OPENCLAW_COMMAND
runner	Agent CLI command; default openclaw
CLAWQUEUE_DELIVER_CHANNEL
runner	OpenClaw worker delivery channel; use none /off to avoid chat delivery dependency
CLAWQUEUE_COMPLETION_NOTIFY_CHANNEL
notifier	Best-effort completion notification channel, e.g. telegram
CLAWQUEUE_COMPLETION_NOTIFY_TARGET
notifier	Completion notification target, or last-telegram to reuse this instance’s most recent Telegram direct chat
CLAWQUEUE_MODES_DIR
runner	Local mode prompt directory
CLAWQUEUE_MODES_BASE_URL
runner	Fallback raw URL for mode prompts
CLAWQUEUE_ALL_OPUS
routing	Route implementation modes through ceo when true
CLAWQUEUE_MODE_TO_AGENT_JSON
routing	JSON map overriding mode-to-agent routing
CLAWQUEUE_AGENT_PROVIDER_JSON
quota	JSON map for provider quota checks
CLAWQUEUE_AGENT_FALLBACK_JSON
quota	JSON map for exhausted-provider fallback agents
CLAWQUEUE_DAILY_WARN_REMAINING_PCT
quota	Warn when provider daily/primary quota is at or below this remaining percent; default 10
CLAWQUEUE_WEEKLY_WARN_REMAINING_PCT
quota	Warn when provider weekly/secondary quota is at or below this remaining percent; default 20
CLAWQUEUE_DAY_STOP_REMAINING_PCT
quota	Stop/reroute when daily/primary remaining quota is at or below this percent; default 5
CLAWQUEUE_WEEKLY_STOP_REMAINING_PCT
quota	Stop/reroute when weekly/secondary remaining quota is at or below this percent; default 0 (disabled)
CLAWQUEUE_REVIEWER_AUTO_CLOSES_ISSUE
runner	Whether reviewer agents close issues after passing review
CLAWQUEUE_MAX_ATTEMPTS_PER_ISSUE
dispatcher	Per-issue dispatch attempt cap
CLAWQUEUE_MIN_RUN_INTERVAL_MIN
dispatcher	Throttle between successful dispatches
CLAWQUEUE_IDLE_TIMEOUT_MIN
activity	Require this many idle minutes before dispatching
CLAWQUEUE_USER_ACTIVE_GATE_MIN
activity	Skip or ask when recent user activity is detected
CLAWQUEUE_DECISION_LOG_RETENTION_DAYS
dispatcher	Days to keep in ~/.local/share/clawqueue/decisions.jsonl
CLAWQUEUE_TELEGRAM_BOT_TOKEN
notifier	Telegram bot token for ask flow
CLAWQUEUE_TELEGRAM_CHAT_ID
notifier	Telegram chat ID for ask flow
OPENCLAW_HOME
config	Base OpenClaw directory; default ~/.openclaw
OPENCLAW_WORKSPACE
config	OpenClaw workspace; used for modes and memory files

GitHub ProjectV2 mutations need node IDs that must not be committed. Put them in config/clawqueue.private.json

:

{
  "github": {
    "assignee": "your-github-login"
  },
  "projects": {
    "MT": {
      "project_id": "<github-project-node-id>",
      "field_id": "<github-project-status-field-id>",
      "status_options": {
        "todo": "option-id-for-todo",
        "in_progress": "option-id-for-in-progress",
        "done": "option-id-for-done"
      }
    }
  }
}

Use CLAWQUEUE_PROJECTS_JSON

for the same data in CI or a secret-managed runtime.

CQ stays local-first and solo-operator friendly, but it mirrors the useful state back to GitHub:

• one managed progress comment per issue, marked with <!-- clawqueue:progress -->

• tiny worker result comments, marked with <!-- clawqueue:result -->

and<!-- clawqueue:done -->

• issue comments as simple commands: /cq diagnose

,/cq run

,/cq retry

,/cq

• issue/comment text is treated as untrusted task data in worker prompts

Workers should not directly close issues or move board status. They report a small result object and CQ applies final state:

{
  "status": "done",
  "summary": "Brief operator-facing summary.",
  "files_changed": ["relative/path-or-github-url"],
  "review_level": "standard",
  "extra_review_required": false
}

review_level

is issue-intake policy, not worker vibes. The chief-of-staff assistant should set review_level: standard

for ordinary scoped changes and review_level: extra

for high-risk, broad, security-sensitive, public-facing, or hard-to-verify changes. Workers and reviewers report extra_review_required: true

only when another stronger pass is still needed before acceptance. Older needs_review

result comments are still accepted as a compatibility alias.

Supported commands:

Command	Effect
/cq diagnose
Update the managed comment with CQ blockers and next action; /cq status is a compatibility alias
/cq run
Ensure the issue is on the board and queued in Todo
/cq retry
Remove cq:d /cq:failed /cq:blocked , unassign, reset attempts, requeue
/cq
Add cq:d , unassign, skip until retry

CQ-owned state labels: cq:d

, cq:failed

, cq:blocked

.

CQ deliverable labels:

cq:artifact

— agent-side label for a durable Markdown/report/spec deliverable. Workers avoid product/source mutations unless the issue explicitly asks for them. Generated artifacts go to the configured local/worklog artifact destination, not into the code/profile PR branch.cq:change

— agent-side label for a source/content/config/docs change deliverable with verification evidence.

Use exactly one deliverable label when possible. If missing, CQ infers one from the issue title/body and adds the inferred label before dispatch.

Company profile safety can restrict cq:change

to trusted GitHub issue authors:

"safety": {
  "change_author_allowlist": ["github-user", "operator-alt"]
}

When the allowlist is set, CQ blocks unauthorized cq:change

issues with cq:blocked

before dispatch. cq:artifact

remains suitable for broader intake.

Each scheduler run:

• Trims the decision log to the configured retention window
• Sweeps stale In Progress

board items - Exits if another dispatcher or worker is active

• Applies the throttle and attempt-count limits
• Reads open issues from configured repos
• Picks the highest-priority eligible issue from each project’s configured dispatch_statuses

; issues with explicitdepends on Issue #N

/depends on #N

lines wait until those dependencies have a completion result after their latest retry - Defaults to Todo

only; profiles can opt into other statuses explicitly - Checks provider quota via codexbar

when available, including Codex daily/primary and weekly/secondary remaining quota windows - Warns when configurable remaining-quota thresholds are crossed, then stops/reroutes if stop thresholds are crossed

• Assigns the issue, moves it to In Progress

, and starts the selected agent

Runtime state lives in CLAWQUEUE_STATE_DIR

(default: temp dir named clawqueue

; launchd installs use a per-label directory). Decision log persists under CLAWQUEUE_LOG_DIR

(default: ~/.local/share/clawqueue

; launchd installs use a per-label directory).

python3 scripts/status.py

ClawQueue assumes a trusted operator on a trusted local machine. It shells out to gh

, codexbar

, and openclaw

. Do not expose it as a public service without authentication, authorization, command sandboxing, audit logging, and a proper secret manager.

Agents are internal team assistants. External-facing work is draft-only until a human approves it. Human approval is required before:

• Publishing, sending, pricing, or promising anything externally
• Outbound sales, partnerships, or official communications
• Commercial terms, legal/financial/regulatory claims
• Official roadmap commitments or company authority

Tracked files must not contain bot tokens, chat IDs, ProjectV2 node IDs, personal absolute paths, or private assignees. Run a local secret scan before sharing.

ClawQueue ships a compact docs/brand system: full horizontal logo, mascot hero art, deep navy workflow panels, orange/red claw-gradient CTAs, Space Grotesk

headings, and Inter

body copy.

The current implementation lives in:

— custom docs homepagedocs/.vitepress/theme/components/HomePage.vue

— active VitePress theme tokens/componentsdocs/.vitepress/theme/style.css

— design system root note and asset usagedocs/.vitepress/brand/README.md

— public logo, mascot, favicon, CSS, and token assetsdocs/public/brand/

Use docs/public/brand/png/clawqueue-logo-full-horizontal.png

for the root README/header logo. Do not point docs at the old missing docs/banner.svg

.

python3 -m py_compile scripts/scheduler.py clawqueue/*.py

python3 -m unittest

git diff --stat && git diff

source & further reading

github.com — original article