Discord Threads as Resumable Agent Sessions
Maps Discord thread identity to local Pi session files, matching joelclaw's durable agent-session and gateway patterns.
pi-discord-threads turns a Discord thread into the handle for a real local Pi coding-agent session file. That is the clever bit: the chat surface is not the memory. The thread is the remote control, and Pi is still doing the work locally.
Joel described it in Slack as “working so well”: resumable threads in Discord, each thread an ongoing agent session, with channels setting folder context. That means Discord channels become lightweight workrooms. Start with !pi <prompt> or /pi ask, keep talking in the created thread, and the bridge routes the message back into the same local session instead of creating another disposable chat blob.
The useful pattern is identity mapping: Discord thread → local session registry → workspace cwd → continuing Pi process. It also has the unglamorous shit that makes it operable: /pi esc, /pi abort, explicit URL ingest, attachment handling, macOS LaunchAgent support, local release snapshots, and optional Redis run control for active-run coordination.
This is not “agent in chat” as a novelty. It is a concrete interface pattern for joelclaw: use a normal human conversation surface, but bind it to durable local execution and resumable state.
Key Ideas
- Discord threads work as stable session IDs for Pi coding-agent, so the conversation can resume later without losing the underlying session file.
- Discord channels can carry workspace context, so “where should this run?” becomes part of the room instead of repeated prompt boilerplate.
- Explicit
/pi ingestand/pi capturekeep link capture intentional, which fits the joelclaw habit of making durable notes without silently eating every URL. /pi escand/pi abortmake run control visible from the chat surface, which matters when the agent is doing real local work and not just answering questions.- Local release snapshots and macOS LaunchAgent support make the bridge something you can actually leave running without relying on random
nohuppain. - Optional Redis run control points toward multi-process durability: one active run per logical thread, leases, heartbeats, reconcile, and idempotent final-answer posting.