Most AI coding tools treat a session like a phone call: you talk, it answers, you hang up, and everything it knew is gone. Close the tab, lose the thread. Restart the terminal, start over. For a quick question that's fine. For real work — a refactor you pick up across three days, a monitor that watches your CI, an agent that reacts to a push — it's maddening.

Octomind treats sessions as first-class, persistent things. They have names. They survive a crash. They can run in the background, accept messages from other processes, schedule their own future actions, and react to webhooks. This guide builds from "don't lose my work" up to "an agent that runs itself."

The Foundation: Named, Resumable Sessions

Every conversation is a session, and a session is a real artifact on disk, not a transient buffer. Name one when you start it:

bash
octomind run --name feature-auth

Walk away, close the terminal, reboot your laptop. When you come back:

bash
octomind run --resume feature-auth

Everything is there — the conversation, the decisions, the context. Don't remember the name? --resume-recent picks up the last session in this directory, and /list from inside any session shows them all. You can even hop between them mid-conversation with /session feature-auth.

Sessions live in ~/.local/share/octomind/sessions/ as append-only, compressed logs — so they grow as you work rather than getting rewritten, and a crash mid-task doesn't corrupt them. The practical upshot: the cost of stopping work is zero. You never "finish for the day" to avoid losing state, because there's no state to lose.

This pairs with Octomind's automatic context compression — a session can run for hours, compress old context to stay affordable, and still resume cleanly tomorrow.

Daemon Mode: A Session That Stays Alive

A normal session waits for you. A daemon session waits for anything. It stays alive as a background agent after the first turn, and other processes can inject messages into it:

bash
octomind run --name ci-watcher --daemon --format jsonl

Two flags matter here. --daemon keeps it alive; --format jsonl makes it non-interactive and emits structured output (daemon mode requires non-interactive mode — pass a --format or pipe stdin). Now any process on the machine can talk to it:

bash
echo "Check the build status and report failures" | octomind send --name ci-watcher

octomind send finds the running session by name (over a Unix socket on macOS/Linux, a named pipe on Windows) and drops your message into its inbox. The agent processes it like any other turn. This is the primitive everything else builds on: a long-lived agent you can poke from a script, a cron job, or another tool.

Scheduling: An Agent That Remembers to Check Back

Inside a session, the agent can schedule its own future actions with the built-in schedule tool — no external cron needed. You ask in plain language; it sets a timer:

text
> Start the test suite in the background, then check the results in 5 minutes

AI: shell("cargo test --release > /tmp/test.txt 2>&1 &", background=true)
    schedule(command="add", when="in 5m",
      message="Read /tmp/test.txt and report results. If anything failed, analyze it.")

Five minutes later that message fires automatically and the agent reads the results, reports, and suggests fixes — all without you prompting it. The time grammar is flexible: in 30m, in 1h30m, 3:30pm, 2026-12-25 09:00, or idle to fire the next time the session goes quiet. Use every for repeats (every="10m", every="idle").

You don't have to go through the AI, either — the /schedule slash command gives you direct control:

text
/schedule add when="9am" message="run the linter and summarize issues" every="24h"
/schedule list
/schedule remove abc12345

This is the "check the build in ten minutes, remind me about the deploy at 3, run the linter every morning" layer. The full pattern catalog — monitoring loops, build-check-fix cycles, and more — lives in Scheduled Tasks.

Webhooks: An Agent That Reacts to the World

The last layer turns a daemon into an event-driven AI agent. A webhook hook is an HTTP listener that pipes incoming payloads through a script and injects the result into your session. Define one in config:

toml
[[hooks]]
name = "github-push"
bind = "0.0.0.0:9876"
script = "/path/to/process-github-push.sh"
timeout = 30

The script reads the raw request body on stdin and prints a message on stdout — that message gets injected into the session:

bash
#!/bin/bash
payload=$(cat)
repo=$(echo "$payload" | jq -r '.repository.full_name')
branch=$(echo "$payload" | jq -r '.ref' | sed 's|refs/heads/||')
echo "New push to $repo ($branch). Review the changes and flag anything risky."

Activate it when you launch the daemon:

bash
octomind run --name ci-bot --daemon --format jsonl --hook github-push

Now GitHub posts to your listener on every push, the script summarizes it, and your agent reviews the changes — unprompted. Swap the script and you've got a Slack bot, a PR reviewer, a deploy monitor. (If you want code review specifically on every PR, we built a ready-made GitHub Action for that too.) The hook system has a clean HTTP contract — 200 when it injects, 204 when the script ran but produced nothing, 405 for non-POST — so the sender can tell what happened. It's all in Daemon and Hooks.

Putting It Together

These four layers stack into a spectrum. At one end: a named session you resume across days so you never lose work. At the other: a daemon that schedules its own checks, reacts to webhooks, and runs for weeks — a genuine background teammate that monitors your project and pings you when something needs a human.

You don't need all of it. Most days I just want --resume feature-auth so closing my laptop doesn't cost me anything. But the day you want an agent that watches CI, fixes the flaky test, and tells you in Slack — the same primitives are right there. Sessions, daemon, schedule, hooks. Start with resume; grow into the rest.

Get Octomind — sessions that outlive your terminal.