OpenViSTAI · Agents · Blockchain · Crypto
Submit a project
Menu
Agent Frameworks

Cyberclaw

CyberClaw is an MIT-licensed Python and LangGraph framework for running self-hosted, command-line AI agents with tool use, persistent sessions, dynamic skills, scheduled tasks, sub-agent delegation and structured local behaviour logs.

Explore the practical guide ↓

Independent OpenViST project profile, based on linked sources.

Cyberclaw — OpenViST project profile in Agent Frameworks.
OpenViST project illustration. See the linked sources for product details.
Understand the project

Practical overview

When it fits

Use CyberClaw when a local CLI agent needs persistent sessions, inspectable tool activity or process-internal delegation, and when the developer can prepare the model-provider configuration and workspace skills.

Who it is for

  • Developers building self-hosted general-purpose AI agents
  • Teams needing local visibility into model and tool activity
  • Python developers extending LangGraph-based agent workflows
  • Builders adding scheduled tasks or delegated analysis to an agent application

Documented uses

  • Build an agent workflow that connects model decisions, tool actions and observed results.
  • Persist agent sessions and graph checkpoints in SQLite.
  • Load skills on demand and validate their execution protocol before running them.
  • Schedule one-time or recurring tasks within the agent process.
  • Delegate code-review or document-analysis work to scoped sub-agents.
Before you choose

Requirements & limits

The repository is public and MIT-licensed. The documented setup uses Python 3.10 or newer and supports Linux, Windows and macOS; the quick-start command sequence is shown for Linux or WSL2.

  • The framework is a single-machine CLI application, so it suits local workflows rather than a documented background job service.
  • SQLite checkpoints can restore graph state, but they do not provide exactly-once execution for external tool side effects.
  • The default long-term profile is a global file and is not isolated per user.
  • Shell execution uses command and path checks with a 60-second timeout, but it has no independent resource quota and timeout does not guarantee that all child processes stop.
  • Sub-agent calls have separate contexts and configurable tool allowlists, while the default child graph is not persisted across restarts.

Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.

Source-based practical guide

Set up a local CyberClaw agent

Install CyberClaw, configure a model provider and start its CLI.

Before you start

  • Python 3.10 or newer
  • Linux or WSL2 for the documented command sequence
  • A model provider setting, model name, API key and, where needed, base URL

Steps

  1. Clone the CyberClaw repository and enter its directory.

  2. Create and activate a Python virtual environment.

  3. Install the project with pip in editable mode.

  4. Run cyberclaw config to write model settings and test ordinary-message connectivity.

  5. Run cyberclaw run to start the CLI.

Expected outcome

A configured CyberClaw CLI session is started from the local project environment.

Guide limitations

  • The documented connectivity check is not a compatibility guarantee for every provider branch.
  • Anthropic and Ollama branches require additional packages or a running local model service.
  • Heartbeat tasks stop with the main process.
Documentation 1 ↗
Source-based practical guide

Add and invoke a dynamic skill

Place a skill in the workspace and use CyberClaw’s help-to-run credential flow.

Before you start

  • A running CyberClaw workspace
  • A skill directory under workspace/office/skills//
  • A SKILL.md or README.md and any required script dependencies
  • A thread_id for SDK-style invocation

Steps

  1. Create the skill directory and place its instruction file and scripts inside it.

  2. Load the dynamic skills and request help for the selected skill.

  3. Extract the returned help_token and pass it with the command in a run request using the same session configuration.

  4. If execution fails or the instructions change, request help again before retrying.

Expected outcome

The skill receives a run request only after the current instruction-bound credential is validated.

Guide limitations

  • The credential does not prove that the model understood the instructions, that execution is safe or that the user authorised it.
  • Skill scripts, dependencies and commands must be prepared by the deployer.
  • The protocol applies to dynamic skills; the built-in shell tool is separate.
Documentation 1 ↗
Evidence and transparency

Sources & review

Official repository ↗
Source record details
Source availability
Active
Sources checked
3 October 2026
Original website title
ttguy0707/CyberClaw · Official homepage title · retained in its source language
How we review sourcesSuggest a correction