Problem
Webhook hook mappings (e.g., Gmail Pub/Sub) create a new session per event via sessionKey templating:
{
"sessionKey": "hook:gmail:{{messages[0].id}}",
...
}
These sessions accumulate forever with no built-in cleanup mechanism. Over time this leads to:
- Hundreds/thousands of orphaned session entries in
sessions.json
- Orphaned transcript
.jsonl files consuming disk space
- In my case: 358 sessions / 44MB before manual cleanup
Proposed Solution
Add a cleanup option to webhook mappings, similar to what sessions_spawn already supports:
{
"match": { "path": "gmail" },
"action": "agent",
"sessionKey": "hook:gmail:{{messages[0].id}}",
"cleanup": "delete", // <-- new option
...
}
Options could mirror sessions_spawn:
"delete" — remove session + transcript after completion
"keep" — current behavior (default for backwards compat)
Current Workaround
I'm running a cron job that periodically cleans up *:hook:* sessions older than 5 minutes:
jq 'with_entries(select(
(.key | contains(":hook:") | not) or
(($now - (.value.updatedAt // 0)) <= $maxAge)
))' sessions.json
This works but is hacky and requires external maintenance.
Context
- Webhook hooks are typically fire-and-forget (email triage, notifications, etc.)
- Session history has no value after the single turn completes
- The
sessions_spawn precedent shows this pattern is already understood
Problem
Webhook hook mappings (e.g., Gmail Pub/Sub) create a new session per event via
sessionKeytemplating:{ "sessionKey": "hook:gmail:{{messages[0].id}}", ... }These sessions accumulate forever with no built-in cleanup mechanism. Over time this leads to:
sessions.json.jsonlfiles consuming disk spaceProposed Solution
Add a
cleanupoption to webhook mappings, similar to whatsessions_spawnalready supports:{ "match": { "path": "gmail" }, "action": "agent", "sessionKey": "hook:gmail:{{messages[0].id}}", "cleanup": "delete", // <-- new option ... }Options could mirror
sessions_spawn:"delete"— remove session + transcript after completion"keep"— current behavior (default for backwards compat)Current Workaround
I'm running a cron job that periodically cleans up
*:hook:*sessions older than 5 minutes:This works but is hacky and requires external maintenance.
Context
sessions_spawnprecedent shows this pattern is already understood