Skip to content

Conversation

@bborn
Copy link
Owner

@bborn bborn commented Jan 11, 2026

Summary

Add Sprites (Fly.io managed sandboxes) as an execution environment for Claude tasks. Sprites provide isolated VMs where Claude can run with --dangerously-skip-permissions safely.

Architecture: Sprite as execution environment only

┌─────────────────────┐              ┌─────────────────────┐
│   Local Machine     │              │       Sprite        │
│                     │              │                     │
│  ┌───────────────┐  │              │  ┌───────────────┐  │
│  │   task TUI    │  │              │  │    Claude     │  │
│  │   + daemon    │  │   executes   │  │  (isolated)   │  │
│  │   + database  │──┼──────────────▶  │               │  │
│  └───────────────┘  │              │  └───────┬───────┘  │
│         ▲           │              │          │          │
│         │           │   tail -f    │          ▼          │
│         └───────────┼──────────────┼── /tmp/task-hooks   │
│                     │   (hooks)    │                     │
└─────────────────────┘              └─────────────────────┘

Key changes:

  • Task app runs locally - database, TUI, daemon all stay on your machine
  • When SPRITES_TOKEN is set, Claude executes on sprite instead of local tmux
  • Hooks stream back via file tailing (/tmp/task-hooks.jsonl)
  • No database syncing needed - sprite is just a sandbox

New files:

  • internal/sprites/sprites.go - Shared token/client logic
  • internal/executor/executor_sprite.go - SpriteRunner + hook streaming
  • cmd/task/sprite.go - CLI commands for sprite management

Usage:

# Set token (once)
export SPRITES_TOKEN=<your-token>
# or: task sprite token <your-token>

# Run task normally - Claude now executes on sprite
task

# Manual sprite management
task sprite status   # Show sprite status
task sprite up       # Start/restore sprite
task sprite down     # Checkpoint and suspend
task sprite attach   # Interactive shell on sprite
task sprite destroy  # Delete sprite

Test plan

  • Set SPRITES_TOKEN and verify Claude runs on sprite
  • Verify hooks update task status in real-time
  • Test task sprite subcommands
  • Verify local execution still works without token

🤖 Generated with Claude Code

bborn and others added 4 commits January 10, 2026 18:08
Explores using Sprites (sprites.dev) as isolated cloud execution
environments for Claude instances. This could simplify or replace
the current `taskd` cloud deployment approach.

Key findings:
- Sprites provide VM-level isolation with persistent filesystems
- Designed specifically for AI agent workloads
- ~$0.46 for a 4-hour Claude session
- Could eliminate need for dedicated cloud server
- Hook callbacks would work via HTTP

Proposes phased implementation from PoC to full cloud mode.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add support for running Claude tasks on Fly.io Sprites - isolated
cloud VMs that enable dangerous mode safely.

Key features:
- `task sprite init <project>` - Create sprite, clone repo, setup deps
- `task sprite status` - Show sprite status for projects
- `task sprite destroy <project>` - Delete a project's sprite
- `task sprite attach <project>` - SSH into sprite's tmux session
- `task sprite sync <project>` - Pull latest code, update deps
- `task sprite checkpoint <project>` - Save sprite state

Architecture:
- One sprite per project (persistent dev environment)
- Claude runs in dangerous mode inside isolated VM
- Hook events stream via tail -f over WebSocket
- User input sent via tmux send-keys

Database:
- Added sprite_name and sprite_status columns to projects table

Executor:
- Automatically uses sprite if project has one configured
- Hook streaming via tail -f /tmp/task-hooks.log
- Polls for completion, respects status from hooks

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Simplify the Sprites integration from per-project sprites to a single
shared sprite that runs the entire task daemon + TUI.

Changes:
- Auto-connect to sprite when SPRITES_TOKEN is set
- Add --local flag to force local execution
- Remove per-project sprite complexity (executor_sprite.go, client wrapper)
- Sprite runs `task -l --dangerous` with TTY attached
- User's local machine acts as thin client to cloud sprite

This approach is simpler and more cost-effective: one sprite handles
all projects, dangerous mode is safe inside the isolated VM.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Simplify sprites architecture: sprites are now only used as the
execution environment for Claude, not for running the entire task app.

Key changes:
- Task app runs locally (or on remote server), database stays local
- When SPRITES_TOKEN is set, executor runs Claude on sprite instead of local tmux
- Hooks stream back from sprite via tail -f on /tmp/task-hooks.jsonl
- No database syncing needed - sprite is just a sandbox for Claude

New files:
- internal/sprites/sprites.go - Shared sprite client/token logic
- internal/executor/executor_sprite.go - Sprite execution + hook streaming

Flow:
1. User runs `task` locally (normal)
2. Executor checks SPRITES_TOKEN at startup
3. If set, creates SpriteRunner and starts hook listener
4. When task runs, Claude executes on sprite in tmux session
5. Hooks write to file on sprite, executor tails and updates local DB

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants