Claw Code is not the serious production project here.
This repository is closer to a museum exhibit than a product pitch, a
crustacean-run artifact kept alive by clawed gajaes, swept and labeled
by agents, and automatically maintained according to the harnesses
above.
As already described in the project philosophy, this is not meant to be hand-operated like a normal product repo. It is an agent-managed exhibit: the harnesses plan, execute, verify, label, and preserve the artifact while the crabs keep the tank running.
If you want to actually run work, start with LazyCodex or Gajae-Code. If you want to inspect the strange little fossil of the Claw Code moment, continue below.
For the longer public explanation behind this philosophy, see here.
Claw Code is the public Rust implementation of the claw CLI agent harness.
The canonical implementation lives in rust/, and the current source of truth for this repository is ultraworkers/claw-code.
ACP / Zed status:claw-code does not ship an ACP/Zed daemon or JSON-RPC entrypoint yet. Run claw acp (or claw --acp) for the current status instead of guessing from source layout; claw acp serve is currently a discoverability alias only, returns status with exit code 0, and real ACP support remains tracked separately in ROADMAP.md. For the public JSON contract, see docs/g011-acp-json-rpc-status-contract.md.
Current repository shape
rust/ — canonical Rust workspace and the claw CLI binary
USAGE.md — task-oriented usage guide for the current product surface
PARITY.md — Rust-port parity status and migration notes
ROADMAP.md — active roadmap and cleanup backlog
PHILOSOPHY.md — project intent and system-design framing
src/ + tests/ — companion Python/reference workspace and audit helpers; not the primary runtime surface
Quick start
Note
[!WARNING]
cargo install claw-code installs the wrong thing. The claw-code crate on crates.io is a deprecated stub that places claw-code-deprecated.exe — not claw. Running it only prints "claw-code has been renamed to agent-code". Do not use cargo install claw-code. Either build from source (this repo) or install the upstream binary:
This repo (ultraworkers/claw-code) is build-from-source only — follow the steps below.
# 1. Clone and build
git clone https://github.com/ultraworkers/claw-code
cd claw-code/rust
cargo build --workspace
# 2. Set your API key (Anthropic API key — not a Claude subscription)export ANTHROPIC_API_KEY="sk-ant-..."# 3. Verify everything is wired correctly
./target/debug/claw doctor
# 4. Run a prompt
./target/debug/claw prompt "say hello"# 5. Start an interactive session
./target/debug/claw
Note
Windows (PowerShell): the binary is claw.exe, not claw. Use .\target\debug\claw.exe or run cargo run -- prompt "say hello" to skip the path lookup.
Windows setup
PowerShell is a supported Windows path. Use whichever shell works for you. The common onboarding issues on Windows are:
Install Rust first — download from https://rustup.rs/ and run the installer. Close and reopen your terminal when it finishes.
Verify Rust is on PATH:
cargo --version
If this fails, reopen your terminal or run the PATH setup from the Rust installer output, then retry.
Clone and build (works in PowerShell, Git Bash, or WSL):
git clone https://github.com/ultraworkers/claw-code
cd claw-code/rust
cargo build --workspace
Git Bash / WSL are optional alternatives, not requirements. If you prefer bash-style paths (/c/Users/you/... instead of C:\Users\you\...), Git Bash (ships with Git for Windows) works well. In Git Bash, the MINGW64 prompt is expected and normal — not a broken install.
Post-build: locate the binary and verify
After running cargo build --workspace, the claw binary is built but not automatically installed to your system. Here's where to find it and how to verify the build succeeded.
Binary location
After cargo build --workspace in claw-code/rust/:
Debug build (default, faster compile):
macOS/Linux:rust/target/debug/claw
Windows:rust/target/debug/claw.exe
Release build (optimized, slower compile):
macOS/Linux:rust/target/release/claw
Windows:rust/target/release/claw.exe
If you ran cargo build without --release, the binary is in the debug/ folder.
Verify the build succeeded
Test the binary directly using its path:
# macOS/Linux (debug build)
./rust/target/debug/claw --help
./rust/target/debug/claw doctor
# Windows PowerShell (debug build)
.\rust\target\debug\claw.exe --help
.\rust\target\debug\claw.exe doctor
PowerShell smoke commands that do not require live credentials:
$env:CLAW_CONFIG_HOME=Join-Path$env:TEMP"claw config home"New-Item-ItemType Directory -Force -Path $env:CLAW_CONFIG_HOME|Out-NullRemove-Item Env:\ANTHROPIC_API_KEY, Env:\ANTHROPIC_AUTH_TOKEN, Env:\OPENAI_API_KEY -ErrorAction SilentlyContinue
.\rust\target\debug\claw.exe help
.\rust\target\debug\claw.exe status
.\rust\target\debug\claw.exe config env
.\rust\target\debug\claw.exe doctor
If these commands succeed, the build is working. claw doctor is your first health check — it validates your API key, model access, and tool configuration.
Optional: Add to PATH
If you want to run claw from any directory without the full path, choose one of these approaches:
Build and install to Cargo's default location (~/.cargo/bin/, which is usually on PATH):
# From the claw-code/rust/ directory
cargo install --path . --force
# Then from anywhere
claw --help
Option 3: Update shell profile (bash/zsh)
Add this line to ~/.bashrc or ~/.zshrc:
export PATH="$(pwd)/rust/target/debug:$PATH"
Reload your shell:
source~/.bashrc # or source ~/.zshrc
claw --help
Troubleshooting
"command not found: claw" — The binary is in rust/target/debug/claw, but it's not on your PATH. Use the full path ./rust/target/debug/claw or symlink/install as above.
"permission denied" — On macOS/Linux, you may need chmod +x rust/target/debug/claw if the executable bit isn't set (rare).
Debug vs. release — If the build is slow, you're in debug mode (default). Add --release to cargo build for faster runtime, but the build itself will take 5–10 minutes.
Note
Auth: claw requires an API key (ANTHROPIC_API_KEY, OPENAI_API_KEY, etc.) — Claude subscription login is not a supported auth path.
Run the workspace test suite after verifying the binary works:
Note: v10.0.4 accidentally contains the removal of CoffeeScript; v10.0.5 puts it back inNote: v11 removes CoffeeScript and converts this codebase to ESM
This repository provides a library that's distributed by npm that you
use for building your own bots. See the documentation
for details on getting up and running with your very own robot friend.
In most cases, you'll probably never have to hack on this repo directly if you
are building your own bot. But if you do, check out CONTRIBUTING.md
Create your own Hubot instance
This will create a directory called myhubot in the current working directory.
Review scripts/example.mjs. Create more scripts in the scripts folder.
Command bus (robot.commands)
Hubot includes a deterministic command subsystem for
slash-style commands. It is safe by default and does not interfere with
legacy hear and respond listeners.
Commands that declare side effects will require confirmation before execution.
The user is asked to confirm. They do so like so:
@hubot yes
@hubot no
@hubot cancel
Aliases are for discovery and search only. They do not execute commands or create proposals. They are intent utterances.
Built-in Help Command
Hubot automatically registers a help command that provides command discovery and documentation:
@hubot help # List all commands
@hubot help tickets # Filter commands by prefix
@hubot help search "create ticket" # Search by keyword, alias, description, or example
name: 'Send Email'on:
push:
branches:
- masterjobs:
deploy:
runs-on: ubuntu-lateststeps:
- name: 'Send Email'uses: hujiulong/action-send-email@masterwith:
# The hostname or IP address to, requiredhost: 'smtp.server.com'# The port to connect to# Default: 587 if is secure is false or 465 if trueport: 587# If true the connection will use TLS when connecting to serversecure: false# Username, requiredusername: ${{ secrets.EMAIL_USERNAME }}# Password, requiredpassword: ${{ secrets.EMAIL_PASSWORD }}# The subject of the email, requiredsubject: 'subject'# The plaintext version of the messagetext: 'text content'# The html version of the messagehtml: '<p>html content</p>'# The email address of the sender# Default: usernamefrom: 'Sender <sender@server.com>'# The email address of the receiverto: 'receiver@server.com'
from https://github.com/hujiulong/action-send-email
Slate lets you build rich, intuitive editors like those in Medium, Dropbox Paper or Google Docs—which are becoming table stakes for applications on the web—without your codebase getting mired in complexity.
It can do this because all of its logic is implemented with a series of plugins, so you aren't ever constrained by what is or isn't in "core". You can think of it like a pluggable implementation of contenteditable built on top of React. It was inspired by libraries like Draft.js, Prosemirror and Quill.
🤖 Slate is currently in beta. Its core
API is useable right now, but you might need to pull request
improvements for advanced use cases, or fixes for some bugs. Some of its
APIs are not "finalized" and will have breaking changes over time as we
discover better solutions. There isn't currently a 1.0 release schedule, we're still getting the architecture right.
🤖 Slate is also contributor-driven. It
is not backed by any huge company, which means that all contributions
are voluntary and done by the people who need them. If you need
something improved, added, or fixed, please contribute it yourself or no
one will. And if you want to become a more active maintainer, let us
know in the Slack channel.
Why?
Why create Slate? Well... (Beware: this section has a few of my opinions!)
Before creating Slate, I tried a lot of the other rich text libraries out there—Draft.js, Prosemirror, Quill,
etc. What I found was that while getting simple examples to work was
easy enough, once you started trying to build something like Medium, Dropbox Paper or Google Docs, you ran into deeper issues...
The editor's "schema" was hardcoded and hard to customize.
Things like bold and italic were supported out of the box, but what
about comments, or embeds, or even more domain-specific needs?
Transforming the documents programmatically was very convoluted.
Writing as a user may have worked, but making programmatic changes,
which is critical for building advanced behaviors, was needlessly
complex.
Serializing to HTML, Markdown, etc. seemed like an afterthought.
Simple things like transforming a document to HTML or Markdown involved
writing lots of boilerplate code, for what seemed like very common use
cases.
Re-inventing the view layer seemed inefficient and limiting.
Most editors rolled their own views, instead of using existing
technologies like React, so you have to learn a whole new system with
new "gotchas".
Collaborative editing wasn't designed for in advance.
Often the editor's internal representation of data made it impossible
to use to for a realtime, collaborative editing use case without
basically rewriting the editor.
The repositories were monolithic, not small and reusable.
The code bases for many of the editors often didn't expose the internal
tooling that could have been re-used by developers, leading to having
to reinvent the wheel.
Building complex, nested documents was impossible.
Many editors were designed around simplistic "flat" documents, making
things like tables, embeds and captions difficult to reason about and
sometimes impossible.
Of course not every editor exhibits all of these issues,
but if you've tried using another editor you might have run into similar
problems. To get around the limitations of their API's and achieve the
user experience you're after, you have to resort to very hacky things.
And some experiences are just plain impossible to achieve.
If that sounds familiar, you might like Slate.
Which brings me to how Slate solves all of that...
Principles
Slate tries to solve the question of "Why?" with a few principles:
First-class plugins. The most important part of Slate is that plugins are first-class entities. That means you can completely
customize the editing experience, to build complex editors like
Medium's or Dropbox's, without having to fight against the library's
assumptions.
Schema-less core. Slate's core logic
assumes very little about the schema of the data you'll be editing,
which means that there are no assumptions baked into the library that'll
trip you up when you need to go beyond the most basic use cases.
Nested document model. The document model
used for Slate is a nested, recursive tree, just like the DOM itself.
This means that creating complex components like tables or nested block
quotes are possible for advanced use cases. But it's also easy to keep
it simple by only using a single level of hierarchy.
Parallel to the DOM. Slate's data model
is based on the DOM—the document is a nested tree, it uses selections
and ranges, and it exposes all the standard event handlers. This means
that advanced behaviors like tables or nested block quotes are possible.
Pretty much anything you can do in the DOM, you can do in Slate.
Intuitive commands. Slate documents are
edited using "commands", that are designed to be high-level and
extremely intuitive to write and read, so that custom functionality is
as expressive as possible. This greatly increases your ability to reason
about your code.
Collaboration-ready data model. The data
model Slate uses—specifically how operations are applied to the
document—has been designed to allow for collaborative editing to be
layered on top, so you won't need to rethink everything if you decide to
make your editor collaborative.
Clear "core" boundaries. With a
plugin-first architecture, and a schema-less core, it becomes a lot
clearer where the boundary is between "core" and "custom", which means
that the core experience doesn't get bogged down in edge cases.
If you have an idea for an example that shows a common use case, pull request it!
Documentation
If you're using Slate for the first time, check out the Getting Started walkthroughs and the Concepts to familiarize yourself with Slate's architecture and mental models.
This is a open-source Rails Content Management System.
== About How Sticker Works
1. Set up your templet files, it should contains <%= sticker_tag %>
In Rails, the model is handled by what's called an object-relational mapping
layer entitled Active Record. This layer allows you to present the data from
database rows as objects and embellish these data objects with business logic
methods. You can read more about Active Record in
link:files/vendor/rails/activerecord/README.html.
The controller and view are handled by the Action Pack, which handles both
layers by its two parts: Action View and Action Controller. These two layers
are bundled in a single package due to their heavy interdependence. This is
unlike the relationship between the Active Record and Action Pack that is much
more separate. Each of these packages can be used independently outside of
Rails. You can read more about Action Pack in
link:files/vendor/rails/actionpack/README.html.
== Getting Started
1. At the command prompt, start a new Rails application using the <tt>rails</tt> command
and your application name. Ex: rails myapp
2. Change directory into myapp and start the web server: <tt>script/server</tt> (run with --help for options)
3. Go to http://localhost:3000/ and get "Welcome aboard: You're riding the Rails!"
4. Follow the guidelines to start developing your application
== Web Servers
By default, Rails will try to use Mongrel if it's are installed when started with script/server, otherwise Rails will use WEBrick, the webserver that ships with Ruby. But you can also use Rails
with a variety of other web servers.
Mongrel is a Ruby-based webserver with a C component (which requires compilation) that is
suitable for development and deployment of Rails applications. If you have Ruby Gems installed,
getting up and running with mongrel is as easy as: <tt>gem install mongrel</tt>.
More info at: http://mongrel.rubyforge.org
Say other Ruby web servers like Thin and Ebb or regular web servers like Apache or LiteSpeed or
Lighttpd or IIS. The Ruby web servers are run through Rack and the latter can either be setup to use
FCGI or proxy to a pack of Mongrels/Thin/Ebb servers.
== Apache .htaccess example for FCGI/CGI
# General Apache options
AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI
# If you don't want Rails to look in certain directories,
# use the following rewrite rules so that Apache won't rewrite certain requests
#
# Example:
# RewriteCond %{REQUEST_URI} ^/notrails.*
# RewriteRule .* - [L]
# Redirect all requests not available on the filesystem to Rails
# By default the cgi dispatcher is used which is very slow
#
# For better performance replace the dispatcher with the fastcgi one
#
# Example:
# RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
RewriteEngine On
# If your Rails application is accessed via an Alias directive,
# then you MUST also set the RewriteBase in this htaccess file.
#
# Example:
# Alias /myrailsapp /path/to/myrailsapp/public
# RewriteBase /myrailsapp
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
# In case Rails experiences terminal errors
# Instead of displaying this message you can supply a file here which will be rendered instead
#
# Example:
# ErrorDocument 500 /500.html
ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"
== Debugging Rails
Sometimes your application goes wrong. Fortunately there are a lot of tools that
will help you debug it and get it back on the rails.
First area to check is the application log files. Have "tail -f" commands running
on the server.log and development.log. Rails will automatically display debugging
and runtime information to these files. Debugging info will also be shown in the
browser on requests from 127.0.0.1.
You can also log your own messages directly into the log file from your code using
the Ruby logger class from inside your controllers. Example:
class WeblogController < ActionController::Base
def destroy
@weblog = Weblog.find(params[:id])
@weblog.destroy
logger.info("#{Time.now} Destroyed Weblog ID ##{@weblog.id}!")
end
end
The result will be a message in your log file along the lines of:
Mon Oct 08 14:22:29 +1000 2007 Destroyed Weblog ID #1
More information on how to use the logger is at http://www.ruby-doc.org/core/
Also, Ruby documentation can be found at http://www.ruby-lang.org/ including:
* The Learning Ruby (Pickaxe) Book: http://www.ruby-doc.org/docs/ProgrammingRuby/
* Learn to Program: http://pine.fm/LearnToProgram/ (a beginners guide)
These two online (and free) books will bring you up to speed on the Ruby language
and also on programming in general.
== Debugger
Debugger support is available through the debugger command when you start your Mongrel or
Webrick server with --debugger. This means that you can break out of execution at any point
in the code, investigate and change the model, AND then resume execution!
You need to install ruby-debug to run the server in debugging mode. With gems, use 'gem install ruby-debug'
Example:
class WeblogController < ActionController::Base
def index
@posts = Post.find(:all)
debugger
end
end
So the controller will accept the action, run the first line, then present you
with a IRB prompt in the server window. Here you can do things like:
>> @posts.inspect
=> "[#<Post:0x14a6be8 @attributes={\"title\"=>nil, \"body\"=>nil, \"id\"=>\"1\"}>,
#<Post:0x14a6620 @attributes={\"title\"=>\"Rails you know!\", \"body\"=>\"Only ten..\", \"id\"=>\"2\"}>]"
>> @posts.first.title = "hello from a debugger"
=> "hello from a debugger"
...and even better is that you can examine how your runtime objects actually work:
>> f = @posts.first
=> #<Post:0x13630c4 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}>
>> f.
Display all 152 possibilities? (y or n)
Finally, when you're ready to resume execution, you enter "cont"
== Console
You can interact with the domain model by starting the console through <tt>script/console</tt>.
Here you'll have all parts of the application configured, just like it is when the
application is running. You can inspect domain models, change values, and save to the
database. Starting the script without arguments will launch it in the development environment.
Passing an argument will specify a different environment, like <tt>script/console production</tt>.
To reload your controllers and models after launching the console run <tt>reload!</tt>
== dbconsole
You can go to the command line of your database directly through <tt>script/dbconsole</tt>.
You would be connected to the database with the credentials defined in database.yml.
Starting the script without arguments will connect you to the development database. Passing an
argument will connect you to a different database, like <tt>script/dbconsole production</tt>.
Currently works for mysql, postgresql and sqlite.
== Description of Contents
app
Holds all the code that's specific to this particular application.
app/controllers
Holds controllers that should be named like weblogs_controller.rb for
automated URL mapping. All controllers should descend from ApplicationController
which itself descends from ActionController::Base.
app/models
Holds models that should be named like post.rb.
Most models will descend from ActiveRecord::Base.
app/views
Holds the template files for the view that should be named like
weblogs/index.html.erb for the WeblogsController#index action. All views use eRuby
syntax.
app/views/layouts
Holds the template files for layouts to be used with views. This models the common
header/footer method of wrapping views. In your views, define a layout using the
<tt>layout :default</tt> and create a file named default.html.erb. Inside default.html.erb,
call <% yield %> to render the view using this layout.
app/helpers
Holds view helpers that should be named like weblogs_helper.rb. These are generated
for you automatically when using script/generate for controllers. Helpers can be used to
wrap functionality for your views into methods.
config
Configuration files for the Rails environment, the routing map, the database, and other dependencies.
db
Contains the database schema in schema.rb. db/migrate contains all
the sequence of Migrations for your schema.
doc
This directory is where your application documentation will be stored when generated
using <tt>rake doc:app</tt>
lib
Application specific libraries. Basically, any kind of custom code that doesn't
belong under controllers, models, or helpers. This directory is in the load path.
public
The directory available for the web server. Contains subdirectories for images, stylesheets,
and javascripts. Also contains the dispatchers and the default HTML files. This should be
set as the DOCUMENT_ROOT of your web server.
script
Helper scripts for automation and generation.
test
Unit and functional tests along with fixtures. When using the script/generate scripts, template
test files will be generated for you and placed in this directory.
vendor
External libraries that the application depends on. Also includes the plugins subdirectory.
If the app has frozen rails, those gems also go here, under vendor/rails/.
This directory is in the load path.
