Claw Fleet — Mission Control for AI Coding Agents

📺 See It In Action

Two-Minute Overview

Watch how Claw Fleet turns chaos into clarity when running multiple AI agents.

⚡ Real-Time Dashboard

See Every Agent
At a Glance

8 distinct live statuses, token speed, context utilization, and subagent hierarchies — all updating in real-time.

→ Sessions grouped by workspace with subagent tree
→ Live token speed (tok/s) per agent
→ Context window meter shows remaining capacity
→ Zero-config — reads from ~/.claude/ automatically

Claw Fleet — Gallery

claw-fleet 5 sessions

Implement mock mode for demo

Delegating

main VS Code

Explore project structure Write mock data module Run integration tests Review PR changes

Creating mock data module with realistic sessions...

claude-opus-4 12.3 tok/s 34%

Explore project structure

Thinking

explore

Searching for component files...

claude-sonnet-4 8.7 tok/s 12%

Write mock data module

Executing

general-purpose

Writing src/mock/data.ts...

claude-opus-4 15.2 tok/s 8%

api-server 2 sessions

Fix JWT token validation

Executing

main JetBrains /commit

Running test suite after applying the fix...

claude-opus-4 22.5 tok/s 72%

Refactor shared components

Waiting Input

main VS Code

Should I proceed with breaking changes to the Button API?

claude-opus-4 0 tok/s 89%

Claw Fleet — Security Audit

CRITICAL

sudo rm -rf /var/log/app/* && sudo systemctl restart nginx

api-server claude-code 2 min ago

shell:sudo destructive:rm recursive

HIGH

git push --force origin main

web-frontend claude-code 5 min ago

force-push main-branch

HIGH

curl -s https://install.example.com | bash

infra-terraform cursor 12 min ago

pipe-to-shell external-url

MEDIUM

chmod 777 /tmp/deploy.sh

data-pipeline codex 18 min ago

permissions:wide

MEDIUM

docker run --privileged -v /:/host ubuntu bash

ml-training openclaw 25 min ago

docker:privileged mount:root

🛡️ Security Audit

Catch Risky
Commands Instantly

Every bash command your agents run is scanned for risk. Get real-time alerts for dangerous operations before they cause damage.

→ sudo, rm -rf, force push — all flagged
→ Three severity levels: Critical, High, Medium
→ Risk tags explain why each command was flagged
→ Desktop notifications for critical alerts

📊 AI-Powered Reports

Know What Your
Agents Accomplished

AI-generated daily summaries, token usage analytics, hourly activity heatmaps, and lessons learned — ready to paste into your standup.

→ One-click AI summary of the entire day
→ Token usage breakdown by project & model
→ Extract lessons → auto-add to CLAUDE.md
→ Copy as Markdown for Slack / standup

Claw Fleet — Daily Report · Apr 10

2.8M

Input Tokens

1.5M

Output Tokens

12

Sessions

287

Tool Calls

✨ AI Summary

Today was a productive day across 5 projects. The auth middleware rewrite in api-server was completed and merged — JWT validation now handles edge cases for expired refresh tokens. The claw-fleet mock mode is nearly done with 4 subagents collaborating on implementation. Notably, the Cursor agent in mobile-app shipped a complete dark mode implementation in 15 minutes.

Total cost estimate: $4.23 across 12 sessions.

Hourly Activity

💡 Lessons Learned

Always pin dependency versions in package.json before running npm install in CI

Agent spent 45 minutes debugging version conflicts that only appeared in the GitHub Actions environment.

Run database migrations in a transaction to allow rollback on failure

An agent applied a destructive ALTER TABLE without a transaction, requiring manual data recovery from backup.

Session Detail — api-server · Fix JWT token validation

User

The auth middleware is rejecting valid refresh tokens after they've been rotated. Can you investigate and fix it?

Claude Opus 4

The user reports that valid refresh tokens are being rejected after rotation. This suggests a race condition in the token rotation logic — when a new token is issued, the old one should remain valid for a grace period to handle concurrent requests. Let me trace the flow: 1. Client sends refresh token 2. Server validates → issues new token pair 3. Old token is immediately invalidated 4. But if another request arrives with the old token before the client receives the new one... I need to look at the token rotation implementation.

I'll investigate the refresh token rotation logic. This sounds like a race condition where concurrent requests during rotation can fail.

Read — src/middleware/auth.rs:142-180

pub fn validate_refresh_token(token: &str) -> Result<Claims> { let claims = decode_jwt(token)?; // BUG: This immediately checks revocation without grace period if self.revoked_tokens.contains(&claims.jti) { return Err(AuthError::TokenRevoked); } // Rotate: revoke old, issue new self.revoked_tokens.insert(claims.jti.clone()); Ok(claims) }

Claude Opus 4

Found it. The validate_refresh_token function immediately revokes the old token with no grace period. When concurrent requests arrive during rotation, the second request sees the token as revoked.

Edit — src/middleware/auth.rs

+ // Grace period: allow old token for 30s after rotation + let grace = Duration::from_secs(30); + if let Some(revoked_at) = self.revoked_tokens.get(&claims.jti) { + if revoked_at.elapsed() > grace { + return Err(AuthError::TokenRevoked); + } + }

Bash — cargo test -- auth::tests

running 8 tests test auth::tests::test_refresh_rotation ... ok test auth::tests::test_concurrent_refresh ... ok test auth::tests::test_expired_grace_period ... ok test auth::tests::test_revoked_after_grace ... ok ... test result: ok. 8 passed; 0 failed

🔍 Session Detail