harflow-mcp

HarflowMCP

HarflowMCP is a local MCP server that dispatches coding tasks to Claude Code, Codex, opencode, Vibe, and Antigravity. It provides persistent task history, bounded reads, cancellation, continuation, and reusable workflows. On measured Claude Code versions, callers can opt in to approving individual Bash, Read, Write and Edit requests one exact action at a time (see harness permissions); on macOS with codex-cli 0.163.0 the same opt-in approves individual Codex commands and, with caller_write_approvals, patches through codex app-server (see Codex caller approvals), and can grant a task a bounded list of specific Bash commands with allowed_commands instead of unrestricted access (see dispatch-time command grants).

Workflow callers can see every pending child question in status and wait replies and answer them independently by decision ID through the root run. Questions and structured clarification items remain complete, and forwarded answers return a durable child acceptance receipt. Resolved attention reasons disappear when execution resumes; unreadable workflow approval metadata is reported separately from requests needing a decision. See workflow input and recovery.

Permission features use cached, binary-bound qualification: measured versions seed the cache, and unseen versions run isolated no-paid behavior probes before use. harflow-ctl qualify <backend> explicitly reruns the probes; discovery and permission previews report their per-feature results. Automatic probes currently require macOS isolation. See qualification.

Current seed measurements for these two features: allowed_commands is qualified on Claude Code 2.1.310 and 2.1.312; caller approvals are qualified on Claude Code 2.1.302 (Bash approvals) and 2.1.310/2.1.312, and on Codex through codex app-server for codex-cli 0.163.0 on macOS only (commands, and patches with caller_write_approvals); other backends refuse them. Approvals are not available to native workflow children, and a request unanswered after 1800 seconds (or at the node's attempt deadline) is rejected by Harflow, never approved. After a denial there is no approve-later path: recovery is always a new resume_task or continue_task execution guided by denial_remedy (allowed_commands covers only Bash approval_required and chained-command parts; a denied Read, Write or Edit needs a resumed run so the agent can raise a fresh request; a deny_rule cannot be lifted by grants). Workflow permission-grant retry and approval notifications are not available. On compatible engines the Mac Monitor can answer caller-owned requests; authority follows the existing inferred, cooperative same-user model and does not authenticate a human or the app. See harness permissions.

Vibe 3.0.1 headless dispatch uses its Rust CLI and the ask approval profile for read_only. This is an approval policy, not a write-tool exclusion: inherited policies or custom profiles can pre-approve writes. The retained VIBE_CLI=python selector is ignored by Vibe 3; interactive takeover inherits the user's environment.

Version 0.0.4 is a pre-release. Harflow, the companion macOS application, is maintained separately and prepares its own exact paired engine runtime. Its managed runtime and MCP registrations work independently of the app process; see the managed runtime guide.

Detached task owners preserve output capture and live input across MCP server restarts. Tasks can take turns on a named, exclusive resource (a simulator, a device, a database) with resources; a waiting task is acknowledged at once and reports waiting_for_resources until it spawns. A task can also run in its own linked Git worktree with worktree, leaving your checkout untouched. Workflows can declare run and node resource scopes and share one root-run worktree across nodes and linked child runs. See resources and worktrees. Final review summaries and workflow plans receive task-identifiable files discoverable through task artifacts, including read-only runs. Child workflows receive pinned parent specifications throughout their nodes. Every task also gets scratch folders shared across its resume chain and its group (HARFLOW_CHAIN_SCRATCH, HARFLOW_GROUP_SCRATCH), so outputs survive between runs; see shared scratch.

Workflow scheduler recovery is explicit; see supervision and recovery. Task status distinguishes the dispatching server, execution owner and responding server. A normal attachment to a task launched by this server is not recovered; another observer or missing identity is explained explicitly. Detail reads separately report dispatcher liveness, and routine status polling provides a successor reference without scanning history. See supervision and recovery. Git outcomes retain partial observations with per-probe failure and budget diagnostics. Commit ranges include imported history and cannot identify task-created commits or authorship; see observed task outcomes. Task observations retry transient metadata replacements up to three reads and retain uncertainty when metadata cannot be read reliably. Recovered tasks disclose owner/process uncertainty and capture continuity. Qualified Claude transcripts can supply bounded display-only recovery activity; see public contracts. Live-input capability does not promise that stdin is still open: status reports `input_

…