Depot Integration — The Wolf's Grievances
Pain points and feature requests for Depot Claude integration, from the Fenrir Ledger engineering team.
We built an autonomous agent orchestration system on top of depot claude.
Multiple agents — engineers, testers, designers — each running in their own sandbox,
each handing off to the next via git commits and GitHub issue comments.
The architecture is sound. The wolf runs.
But the chain that binds us is not the work itself — it is the tooling around it. We have fought these battles long enough to know the difference between friction that sharpens and friction that bleeds. This is the latter.
We are writing this because we want to stay. Depot's sandbox model is the closest thing to what we need. But a wolf that cannot see its pack, cannot hear when the hunt ends, and must claw through the underbrush for every scrap of information — that wolf will eventually find another forest.
If these gaps remain, we will be forced to evaluate alternatives — raw EC2 sandboxes, modal.com, or rolling our own container orchestration. None of those options are as elegant as what Depot could be. That's what makes this worth writing.
What follows are the thorns we pulled from our paws. We offer them not as complaints, but as prey laid at your door — problems worth hunting, before the wolf moves on.
No Simple Way to Retrieve a Session Log
There is no depot claude session-log <id> command.
To get the transcript of what an agent did in a sandbox, we must: search ~/.claude/projects/<hash>/ for JSONL files, filter by file size (Depot sessions are small; local conversations are large), grep inside each file for the session ID or branch name, and if not found locally, run depot claude --wait --resume <id> to trigger a download, then parse the JSONL with jq.
We wrote a 90-line bash script to automate this. It should be one command.
What we want
{`# Get the full session transcript
depot claude session-log
Raw JSONL for piping
depot claude session-log --format jsonl
Just assistant messages, human-readable
depot claude session-log --format text`}
What we have to do instead
{`# Our actual script — this is what "get a log" looks like today
JSONL_FILE=$(find ~/.claude/projects/ -name "*.jsonl" -size -500k \\
-exec grep -l "$SESSION_ID" {} \\;)
if [ -z "$JSONL_FILE" ]; then
depot claude --wait --resume "$SESSION_ID" --org "$ORG_ID" >/dev/null 2>&1
JSONL_FILE=$(find ~/.claude/projects/ -name "*.jsonl" -size -500k \
-exec grep -l "$SESSION_ID" {} \;)
fi
cat "$JSONL_FILE" | jq -r '...' # 40 more lines of jq incantations`}
The wolf should not need to dig through filesystem internals to see what its pack did.
CLI Defaults to Pager — Hostile to Automation
depot claude list-sessions opens an interactive pager by default. This is death for automation.
Every script that calls list-sessions must pass --output json to avoid hanging on a pager that will never receive a keypress. There is no environment variable (DEPOT_PAGER, DEPOT_NO_PAGER, NO_PAGER) to disable this globally.
Even with --output json, the command prefixes a pagination token line before the JSON array, requiring an additional sed -n '/^\[/,$ p' to extract valid JSON. The pagination token should not be mixed into the JSON output — put it in stderr, a header, or a separate --next-token flag.
What we want
{`# Environment variable to disable pager globally
export DEPOT_PAGER=off
Or at minimum, detect non-TTY and disable automatically
depot claude list-sessions | jq '.[0].id' # should just work`}
What we have to do instead
{`depot claude list-sessions --output json 2>/dev/null \\
| sed -n '/^\\[/,$ p' \\
| jq '.[0].id'`}
The wolf does not wait for permission to read its own rune log.
Sessions Are Resumable — But We Want One-Shot
The session model assumes you'll come back. We never do.
The depot claude session model is built around resumption — start a session, leave, come back, resume. This is useful for interactive work. But our use case is fire-and-forget agent dispatch: launch an agent with a prompt, it does its work, it's done. We never resume it. We just want to know when it finishes.
The --wait flag blocks until completion, which helps. But there's no lightweight way to check "is this session done yet?" without either running --wait --resume (blocks and downloads the full session) or listing all sessions and filtering (paginated, pager-hostile — see Grievance II).
What we want
{`# Simple status check — returns immediately
depot claude session-status
{ "id": "...", "status": "completed", "exit_code": 0, "duration": "3m42s" }
Exit-code-based check for scripting
depot claude session-status --quiet
Exit 0 = completed, Exit 1 = running, Exit 2 = failed`}
What we have to do instead
{`# Option A: Block forever
depot claude --wait --resume "$SESSION_ID" --org "$ORG_ID"
Option B: Poll the session list (paginated, pager-hostile)
while true; do
STATUS=$(depot claude list-sessions --output json 2>/dev/null \
| sed -n '/^\[/,$ p' \
| jq -r ".[] | select(.id == \"$SESSION_ID\") | .status")
[ "$STATUS" = "completed" ] && break
sleep 30
done`}
The wolf needs to watch all its pups at once, not sit beside each one until it sleeps.
No Backchannel for Session Completion
When an agent finishes, nothing happens on our end. No webhook. No callback. No event.
Our current architecture is "fire-and-forget, then the human checks manually." This works, but it means the human is the event loop. The wolf is leashed to the handler's schedule.
Our best workaround is to run depot claude --wait --resume as a background process and rely on our CLI framework's task notification system. But this means holding an open process per session, which doesn't scale to 5+ parallel agent chains.
What we want — webhooks
{`# Register a webhook for session lifecycle events
depot claude webhooks add \\
--url "https://our-api.example.com/depot/callback" \\
--secret "$WEBHOOK_SECRET" \\
--events session.completed,session.failed
Signed payload (HMAC-SHA256):
{
"event": "session.completed",
"session_id": "issue-199-step2-loki-fe3adaf1",
"org_id": "pqtm7s538l",
"exit_code": 0,
"duration_seconds": 222,
"repository": "declanshanaghy/fenrir-ledger",
"branch": "fix/issue-199-cards-header-text"
}`}
Or even simpler — per-session callback
{`depot claude \\
--session-id "issue-199-step2-loki" \\
--on-complete "https://our-api.example.com/depot/done" \\
-p "..."`}
The wolf pack hunts in parallel. When one brings down its quarry, the others must know — without stopping to look over their shoulders.
The Hunt List
| Proposed Command | Purpose | Today's Workaround |
|---|---|---|
session-log <id> | Get session transcript | 90-line bash script searching filesystem + jq |
session-status <id> | Check if session is done | --wait --resume (blocking) or poll list-sessions |
webhooks add | Event-driven completion notification | Human-in-the-loop or background --wait per session |
DEPOT_PAGER=off | Disable interactive pager globally | --output json on every invocation + sed to strip tokens |
Why This Matters
Our multi-agent architecture — and why the wolf needs these tools.
{`Orchestrator (local)
|
|-- spawn FiremanDecko (Depot session) --> git push --> handoff comment
| +-- on complete: spawn Loki (Depot session) --> test, merge
|
|-- spawn Luna (Depot session) --> wireframes --> handoff
| +-- on complete: spawn FiremanDecko --> implement --> handoff
| +-- on complete: spawn Loki --> test, merge
|
+-- ... up to 5 parallel chains
Today, every "on complete" requires a human to run /fire-next-up --resume.
With session-status or webhooks, the orchestrator runs autonomously.`}
We chose Depot because the sandboxes are clean, the Claude integration is native, and the fire-and-forget model fits our architecture. The foundation is strong. These are the refinements that would let us — and every team building agent orchestration on Depot — run at full stride.Without them, we build the scaffolding ourselves, and at some point the scaffolding outweighs the platform. That's when the wolf slips its chain and finds open ground.
The wolf is patient. But the wolf is also hungry. And a hungry wolf does not stay leashed for long.
— Fenrir Ledger Engineering