Open source / Self-hosted / Built around native CLIs
Keep your work
within reach.
A workspace for your coding agents.
Continue from your phone. Keep projects organised. Give each session the context to work with the others.
Claude Code, Codex and OpenCode run on your machine, with their native tools and your accounts. Sillage brings the work into your browser.
Your idea. A shared workspace.
Agents that get to work.
You steer from your browser. Everything comes together on your machine.
Your accounts & AI models Your agents
Switch devices.
Keep the session.
Your agents have a home. Follow their work from any device.
Run Sillage on an always-on server, connect through your VPN, and pick up on your phone. Close your browser mid-turn: the agent keeps working, and the event journal brings the conversation back when you reconnect.
Answer a permission request, review a diff or send a correction. Install Sillage as a PWA and receive push notifications when a turn finishes or an agent needs your attention.
Prefer your own computer? Sillage works there too. Keep it awake and online, and set up remote access before switching devices. Your agents and files stay on the machine where you installed them.
Set up remote access & agent preview links ↗- Persistent sessions
- Message queue & steering
- Project-aware dictation
A project lasts longer
than a conversation.
Give the work a place to live, from the first task to the next handover.
Cards with a history
Descriptions, attachments, linked sessions and notes. Start a conversation from a card; the next agent can read what came before.
Room for parallel work
Use the project root, an existing worktree or a new branch. Keep separate changes in separate worktrees while following them from the same project.
The repository at hand
Read files, edit code, inspect diffs and commits, or open a terminal beside the conversation. Search past conversations across projects.
Your agents should know
who else is working.
Two sessions can share a repository without sharing context. Sillage gives them tools to find that context.
Through the built-in MCP server, every agent can discover active sessions, read earlier decisions, identify who edited a file, contact another session and start a new one. The same project history is available to all of them.
- Before starting work
- See active sessions, branches and worktrees.
list_sessions - Before undoing a change
- Find the session that edited a file and check what it is doing.
find_file_edits - When a decision already exists
- Search earlier conversations and read the reasoning.
search_history · read_conversation - When work overlaps
- Message another session, announce a shared change or ask to be notified when it finishes.
send_session_message · broadcast_session_message · notify_when_done - When handing work over
- Read the task and leave a note for the next session.
read_card · add_card_note - When work belongs elsewhere
- Open a card for a bug found along the way. When you ask, start a new session with its own CLI, model, effort and worktree, then get notified when it finishes.
create_card · start_session · list_models
These tools help agents coordinate; they do not lock files or prevent merge conflicts. Use separate worktrees when changes need isolation.
Read the tool definitions ↗Native harnesses.
A shared workspace.
Choose Claude Code, Codex or OpenCode for each conversation. Keep the project around it.
Sillage drives the native CLIs: their tools, permission requests and agent behaviour. Each adapter translates its events into a common format for the interface, history and search.
The board and coordination tools belong to the project, so a Codex session can look up a decision made in a Claude Code conversation. Additional CLIs need their own adapter; Claude Code, Codex and OpenCode are supported today. OpenCode brings any provider and model it can reach, including local ones.
One set of instructions.
One memory.
Claude Code reads CLAUDE.md and keeps its memory under ~/.claude. Codex reads AGENTS.md, OpenCode either one. Sillage gives all three the same context.
Instructions are the rules you set, in a SILLAGE.md with a global part and one per project. They are added to each CLI's prompt: when a session starts for Claude Code and Codex, with every message for OpenCode. A project can keep them in Sillage, and the repository's CLAUDE.md and AGENTS.md are then hidden from agents so nothing arrives twice, or keep them in its repository, edited from the same panel.
Memory is what agents learn while working: one per project, in the format Claude Code already uses. Claude writes it as its native memory, pointed at Sillage's folder; Codex and OpenCode get the index and write through Sillage's tools. What one CLI learns, the others know, and you can read and correct every note.
- When you change the rules
- Ask an agent to revise the instructions; it edits them like a file.
read_instructions · edit_instructions · write_instructions - When something is worth remembering
- Codex and OpenCode note it in the project memory; Claude does it natively in the same folder.
read_memory · write_memory · delete_memory
Both are read when a session starts: a session already running keeps the version it received. Existing projects keep their repository files until you move them into Sillage.
How it works in detail ↗Some work should happen
while you are away.
A release watch every Monday. A dependency audit each night. Sillage runs them on time, in a fresh session, and keeps the results out of your way.
A scheduled task is a prompt with a cadence: every few hours, a cron expression, or a single date. Each run opens a new session of the CLI you chose, with the model, effort and permissions fixed on the task. The agent is told nobody is at the keyboard, gets the date, link and last reply of the previous run, and is cut off after a maximum duration. A run that overlaps the previous one is skipped, or waits.
Runs do not pile up in the session list. They sit under their task in the sidebar, one line per task with its state and last run, and the scheduling page keeps the full history. Neither CLI has a durable scheduler of its own: Claude's cron dies with its session, Codex has none. The daemon that already keeps your sessions alive does this for both.
- When you ask for recurring work
- An agent can schedule it from the conversation, with an interval, a cron expression or a date. You adjust it later from the page.
schedule_task
Runs use the project's default permissions unless the task says otherwise: a run that asks for a permission waits until its time is up. Pick a mode that fits what the task has to do on its own.
A closer look at the workspace
Chat is the middle of it. The repository, the history and the work in flight stay one panel away.
Also in the workspace
The everyday details, covered.
A queue you can steer
Write while the agent runs. Queue a follow-up, withdraw it, or send a correction into the current turn.
Dictation with project vocabulary
Transcription uses a lexicon from your repository and current branch. An optional cleanup pass restores exact spellings. Bring an OpenAI-compatible endpoint.
Shared skills & MCP tools
Keep reusable skills in a central library for Claude Code and Codex. Declare external MCP servers once and choose which agents receive them.
A task API
Create tasks, follow events, answer requests and receive completion webhooks through
/api/v1. Tokens have scopes and optional project restrictions.Processes in view
On Linux, inspect commands and services attached to Sillage, their ports and originating conversations. Detection and limits ↗
Updates from the interface
See when a release is available and read what changed. Native installations can update from the UI; container installations update through their image.
Run it yourself
Your machine.
Your workspace.
An always-on server is recommended for picking up work throughout the day. Your desktop works too, while it stays awake and connected.
Docker, a systemd user service on Linux, a launchd agent on macOS, the same service inside WSL2 on Windows, or a Helm chart. All bind to localhost or stay inside the cluster by default. Add private remote access with a VPN to connect from another device.
# docker-compose.yml
services:
sillage:
image: ghcr.io/marlburrow/sillage:latest
ports: ["127.0.0.1:7317:7317"]
volumes:
- sillage-data:/home/node/.local/share/sillage
- ~/.claude:/home/node/.claude
- ~/.codex:/home/node/.codex
- ~/.local/share/opencode:/home/node/.local/share/opencode
- ~/projects:/home/node/workspace
volumes:
sillage-data:The CLIs are not in the image: install the ones you actually use from the UI, and they land in the data volume. Adjust the mounted paths and authenticate your agents. Start the container, then create the first account:
docker compose up -d
docker compose exec -it sillage node /app/server/cli/user-create.jscurl -fsSL https://raw.githubusercontent.com/MarlBurroW/sillage/main/install.sh | bashLinux x64 or arm64 with systemd. Install the agents you use from the UI, then authenticate them on the host. It installs under ~/.local/share/sillage, fetches Node if the system has none recent enough, sets up a user service and creates the first account. Later updates happen from the UI.
curl -fsSL https://raw.githubusercontent.com/MarlBurroW/sillage/main/install.sh | bashApple Silicon Macs, from Terminal. The same installer as on Linux fetches Node if needed, creates the first account, opens Sillage in your browser and sets up a launchd agent that starts with your session. It needs git: run xcode-select --install first if the Command Line Tools are missing. Your agents only work while the Mac is awake.
# 1. PowerShell, as administrator, then restart
wsl --install
# 2. In the Ubuntu terminal
curl -fsSL https://raw.githubusercontent.com/MarlBurroW/sillage/main/install.sh | bashSillage runs inside WSL2, the Linux built into Windows 10 and 11, and you use it from your Windows browser. The same installer as on Linux enables systemd if the distribution lacks it, fetches Node, creates the first account and adds a Sillage entry to the Start menu. That entry keeps WSL running once the terminal is closed, and can start with Windows.
The agents are the Linux claude, codex and opencode of the distribution, not the Windows ones. Keep projects in the Linux file system, not under /mnt/c. The WSL2 guide covers signing in to the agents, troubleshooting and uninstalling.
Clone the repository first; the chart lives in deploy/helm/sillage. See the Helm installation guide.
helm install sillage ./deploy/helm/sillage \
--namespace sillage --create-namespace \
--set storage.data.storageClass=<block-storage-class> \
--set ingress.enabled=true --set ingress.host=sillage.example.comOne replica, Recreate strategy: the state is a SQLite database on a ReadWriteOnce volume, and two pods writing to it means corruption. Give the data volume a block storage class rather than NFS, whose file locks SQLite cannot rely on. Then create the first account:
kubectl -n sillage exec -it deploy/sillage \
-- node /app/server/cli/user-create.jsWhy I built Sillage
I wanted one place, on a server I own, that I could open from my phone and keep working.
That was the starting point: pick up a project wherever I happen to be, without carrying a laptop or keeping track of a dozen terminals.
I wanted to keep the agents I already used. Sillage runs Claude Code, Codex and OpenCode through their native interfaces, keeping their tools and permission flows. Each has its own adapter; OpenCode also brings access to the providers and local models it supports.
What grew around them is a shared workspace: projects, a board, instructions and memory. An agent can find out what other sessions are doing, read earlier decisions and leave context for whoever picks up the work next, even when they use a different CLI.
Sillage is built with AI, heavily. Claude Code and Codex wrote most of the code, much of it from inside Sillage itself, often from a phone. The tool and the way I work on it grew together.
MarlBurroWCreator of Sillage
A word on security
Sillage is built for a trusted circle, not for the open Internet. Agents run under your system account with your credentials, every account on the instance shares them, and terminal mode is a full shell. The server listens on localhost and does not terminate TLS: reach it through a VPN, a tailnet or a reverse proxy you control.