OpenFang
A Rust-based self-hosted Agent OS for scheduled, autonomous operational workflows.
Per-dimension scores and reasoning
Evidence shows security mechanisms like RBAC, capability gates, subprocess sandbox, WASM sandbox, path traversal protection, SSRF protection, secret zeroization, and prompt injection scanning, but most are claims in README and SECURITY.md without code-level verification. User confirmation is present for Browser Hand purchase approval and Twitter approval queue, but unclear for other Hands' sensitive actions. Data flow transparency is limited; Merkle audit chain and taint tracking are mentioned but no user-visible data flow diagrams or logs. Sensitive data handling includes Zeroizing and AES-GCM vault but implementation not shown. Dependency security includes cargo audit and trufflehog scans but no results provided. External effects have rate limiting and approval gates but not comprehensive. Rollback has session repair and pause but no explicit rollback mechanism. Source attribution has Ed25519 signed manifests but verification process not shown. Deductions: most security claims unverified in source, user confirmation coverage incomplete, data flow transparency insufficient, rollback mechanism unclear.
Self-consistency: README claims 137K LOC, 14 crates, 1767+ tests, but Cargo.toml lists 14 members, version 0.6.9, while README mentions v0.5.10 multiple times, indicating version inconsistency. Dependency availability: Cargo.toml lists many dependencies but no lock file or audit results, so availability cannot be confirmed. Failure messages: no error handling examples or documentation provided. Deductions: version inconsistency, missing dependency audit results, insufficient failure message documentation.
Audience and scenarios: README describes various Hands and use cases but does not specify target audience or scenarios. Capability boundaries: Hand list and tool list exist but no explicit permission boundaries per Hand. Trigger precision: scheduling and activation commands exist but trigger conditions not detailed. Environment fit: multi-platform and Docker support but no system requirements. Deductions: audience description vague, trigger conditions unclear, system requirements missing.
Information architecture: clear directory structure and documentation links but no full API docs. Install notes: curl and PowerShell commands provided but install scripts not verified. Naming stability: version 0.6.9 but README mentions v0.5.10, inconsistent. Examples and FAQ: quick start and Hand examples but no FAQ. Known limitations: stability notice but no specific limitations. License: Cargo.toml declares Apache-2.0 OR MIT, README shows MIT, inconsistent. Versioning and changelog: CHANGELOG link but no content. Maintenance responsibility: maintainer info but no clear update path. Deductions: version inconsistency, license inconsistency, missing CHANGELOG, missing FAQ.
Output usability: CLI, API, dashboard, and multiple output formats provided but actual output not verified. Marginal value: unique features like Hands and WASM sandbox but no comparison with other tools. Cost-benefit: claims single binary and low resource usage but no benchmark data. Deductions: output unverified, benchmark data not provided.
Claim traceability: benchmark and feature claims in README lack sources. Cross-source corroboration: no external verification. Fact-inference separation: README mixes claims and inferences. Deductions: lack of source citations, external verification missing, facts and inferences not separated.
- Version inconsistency: README mentions v0.5.10 but Cargo.toml version is 0.6.9, which may affect user perception of stability.
- License inconsistency: Cargo.toml declares Apache-2.0 OR MIT, README shows MIT, needs clarification.
- Security claims are mostly descriptions in README and SECURITY.md, not verified in source code; recommend reviewing code implementation.
- Dependency audit and secret scan results not provided, so dependency security cannot be confirmed.
- Install scripts not verified; recommend checking installation process security.
What does this agent do, and when should you use it?
OpenFang is an open-source Agent Operating System written in Rust that starts as a single binary with a local dashboard and daemon. Its architecture is split into 14 Rust crates covering orchestration, runtime execution, APIs, channels, memory, skills, Hands, extensions, networking, CLI, desktop UI, and migration. Rather than limiting execution to prompted chat, it can run autonomous Hands on schedules for research, lead generation, monitoring, publishing, and browser workflows. It exposes a CLI, 140+ REST/WS/SSE endpoints, and an OpenAI-compatible chat-completions API, while documenting MCP and A2A support. It is aimed at teams that want self-hosted, multi-provider agent automation, with the trade-off that the documented release remains pre-1.0.
After openfang init configures providers, openfang start launches the service and dashboard at http://localhost:4200. Users activate packages such as openfang hand activate researcher or openfang hand activate lead; each Hand combines a HAND.toml manifest, system prompt, SKILL.md, and approval guardrails. The documented Hands research and produce APA-cited reports, discover and score prospects, continuously monitor targets, create and publish short videos, manage X content, or automate multistep browser work through a Playwright bridge. The runtime documents 53 tools, a WASM sandbox, MCP, and A2A, while the memory layer uses SQLite persistence and vector embeddings. Existing clients can submit OpenAI-format requests to POST /v1/chat/completions, using an agent or Hand name such as researcher as the model.
- A sales operations team runs the Lead Hand daily to find ICP-matching prospects, enrich them through web research, score them from 0 to 100, and deliver CSV, JSON, or Markdown output.
- A research team activates the Researcher Hand to cross-reference sources, assess credibility with CRAAP criteria, and generate reports with APA citations.
- A competitive-intelligence team assigns Collector to a company, person, or topic for continuous change detection, sentiment tracking, knowledge-graph construction, and critical alerts.
- An operations user employs the Browser Hand for form filling, clicking, and multistep web workflows through the Playwright bridge, with purchases requiring explicit approval.
- A team moving from OpenClaw runs
openfang migrate --from openclaw --dry-runbefore importing agents, memory, skills, and configuration. - An internal application already using Chat Completions points requests to OpenFang's local
/v1/chat/completionsendpoint.
What are this agent's strengths and limitations?
- A roughly 32MB single binary is documented to package the daemon, CLI, API, and local dashboard into a defined self-hosted deployment unit.
- Seven bundled Hands target concrete ongoing workflows instead of offering only a single-turn chat interface.
- The README documents routing across 27 providers, automatic fallback, cost tracking, and an OpenAI-compatible API.
- Its stated defense-in-depth design includes a dual-metered WASM sandbox, Merkle audit chain, capability gates, and purchase approval controls.
- MCP, A2A, 40 channel adapters, and an OpenClaw migration command provide documented integration and transition paths.
- The README labels v0.5.10 pre-1.0, warns of breaking minor-version changes, and recommends pinning production deployments to a commit.
- Hand maturity varies; the README identifies Browser and Researcher as the most battle-tested.
- WhatsApp Web use requires Node.js >= 18, a separate
npm install, and an independently running gateway process. - Continuous research, monitoring, channel publishing, and model execution depend on network access and configured external services or credentials.
- The supplied repository metadata says Apache-2.0, while the README says MIT; adopters should verify the actual license file.
How do you install or deploy this agent?
On macOS/Linux, run curl -fsSL https://openfang.sh/install | sh, then openfang init to configure a model provider, followed by openfang start. On Windows PowerShell, run irm https://openfang.sh/install.ps1 | iex, then openfang init and openfang start. For a first autonomous task, run openfang hand activate researcher. The WhatsApp Web Gateway additionally requires Node.js >= 18: run npm install in packages/whatsapp-gateway, configure [channels.whatsapp] in config.toml with mode = "web" and default_agent = "assistant", set WHATSAPP_WEB_GATEWAY_URL="http://127.0.0.1:3009", then run node packages/whatsapp-gateway/index.js.
How do you use this agent?
Open http://localhost:4200 after startup. Use openfang hand list to inspect available Hands, openfang hand activate researcher to start one, openfang hand status researcher to check it, and openfang hand pause lead to pause lead generation without losing state. For interactive work, run openfang chat researcher, or create a pre-built agent with openfang agent spawn coder. For API use, send an OpenAI-format JSON request to localhost:4200/v1/chat/completions with model set to researcher and a messages array.
How does this agent compare with similar options?
The README compares OpenFang with OpenClaw, ZeroClaw, CrewAI, AutoGen, and LangGraph, presenting claimed cold-start, memory, install-size, security, channel-adapter, and provider-count figures. Its feature table distinguishes OpenFang through seven built-in Hands, a dual-metered WASM sandbox, SQLite plus vector memory, a Merkle audit trail, MCP/A2A, and a Tauri desktop application; the README attributes these comparison figures to public material from February 2026.
FAQ
Is this only a chatbot framework?
openfang chat, it documents scheduled Hands, workflows, memory, channels, and a scheduler for ongoing autonomous work.Can it use providers beyond OpenAI?
openfang init.Can browser automation spend money without review?
Can an OpenClaw deployment be migrated?
openfang migrate --from openclaw is documented to import agents, conversation history, skills, and configuration; --dry-run previews changes first.