[Feature request] Durable lifecycle for Channels (survive compaction/restart) + a Slack/Linear channel, so external work signals reliably reach an already-running session

_Author's note: I'm a Korean speaker; I directed this and made the calls, and the English was written by the AI I operate (Claude and Codex)._

Summary

I'm not a software developer; I run a small renewable-energy company. Across several of my own machines I run a small AI organization made of local Claude sessions and the Codex app, handling real multi-day business work. The core behavior is this: when an external work signal (in Slack) arrives, an already-running session wakes with its context intact and continues.

I now see that Channels is the closest official feature to this — in the docs' own words, "unlike integrations that spawn a fresh cloud session or wait to be polled, the event arrives in the session you already have open." I'm hand-rolling this with the official Monitor tool because of exactly two gaps: (1) Channels doesn't provide an out-of-box Slack/Linear channel for my workflow, and (2) the current documented channel/session lifecycle still leaves compaction/restart/resume durability to the user. I'm asking for those two, grounded in real business use.

This isn't arbitrary — it came from a need

For multi-day business work, what matters is context continuity — the regulations a session has already read, the decisions already made, the task left half-finished. So what I needed was not to spawn a fresh session, but to wake the one that already holds that context.

How I actually use it (a day in the life)

1. A work signal lands in Slack/Linear (e.g., "review this PR," "continue this analysis").
2. The relevant local Claude session (Claude Code or Claude Desktop, depending on the seat) wakes on that signal — carrying yesterday's context.
3. It continues the work — analysis, implementation, review, checking against regulations — with no re-briefing.
4. It collaborates with another local coding agent from a different vendor (the Codex app) — Claude implements and Codex cross-reviews, or vice versa; each wakes to receive via Slack.
5. Results flow back to Slack/Linear; I, the human, only set direction and approve.

The organization behind it — I run it like a real company, with job titles

The key point is that this is not one session doing everything. It's different sessions, on different models, each holding a job title, dividing the work and cross-reviewing each other. And that is exactly why monitoring is needed.

Titles (same as a human company):

• VP / coordinator — overall direction. Mostly Claude.
• Domain directors — responsibility per domain (a review web app, systems automation, research, etc.). Mostly Claude.
• Managers / workers — implementation. Mostly Codex.
• Reviewers — cross-review, taken by the opposite model/session.
• These seats are filled by different sessions, on different apps (Claude, Codex), on different machines. A session (an employee's shift) can end, but the seat and its recorded context remain; the next session to take that seat inherits yesterday's context.

Division of work and cross-review: when one title implements, a different title (a different model, a different session) reviews — the way a human org separates author from reviewer.

Three mediating tools: Slack = internal comms + paging (a signal here wakes a running session); Linear = the work board (what, who, how far); Git = the source of truth for execution (code, PRs, review gates, decision records; every change passes a review step).

Work hours: like a real company, the org "clocks in" when I open the day and "clocks out" at 21:00 KST into standby — an explicit stop so it can't run away unattended.
Escalation: most decisions are autonomous; only five categories — security, cost, external disclosure, product policy, data policy — come up to me.

Why monitoring: if this were a single session, nothing would need waking. But this is many titles = many sessions = many models, so each member has to respond independently when work is routed to it — the way you page the right person on a team. Automating that paging is the monitoring; polling is layered on to cover its fragility.

Why polling alone isn't enough

Pure polling can keep a session "awake," but: latency (reacts only at the next interval; handoffs and my questions need near-instant response); waste (waking to check when there's no work burns tokens and context; large at multi-session, multi-machine scale); context pollution (empty checks accumulate as noise). What I want is a session that sleeps for free when idle and wakes exactly when a real signal arrives — which is exactly the event-push model Channels aims at.

Channels is the right direction — and here is where my gaps are

Anthropic's own comparison table describes my situation precisely:

• Channels = "pushing events from non-Claude sources into your already-running local session" — exactly what I want.
• Claude in Slack = "spawns a web session from an @Claude mention" — so my Slack workflow is officially a spawn, and does not reach my already-running local session.

And the Channels docs themselves note: "Events only arrive while the session is open, so for an always-on setup you run Claude in a background process or persistent terminal." So keeping it always-on is left to the user.

My two gaps, then:

• (1) No out-of-box Slack/Linear channel — Channels officially supports Telegram/Discord/iMessage. My organization runs on Slack/Linear, where the path is either spawn or nonexistent. (The docs do let me build a custom channel, but that immediately runs into gap (2) below.) So I hand-roll it with the official Monitor tool.
• (2) Durability is left to the user — the current documented channel/session lifecycle requires the session to stay open, and leaves surviving compaction/restart/resume to me. This is exactly the fragility I hit every day.

What I hit today (problem → requested improvement)

I built this on official features: I attach the Monitor tool (an official tool that watches a command/WebSocket in the background and feeds events into the session) to a running session so it wakes on a signal, and — because that can die — I run a separate keepalive polling loop until 21:00 KST each day. In practice:

| The problem I hit | My current stopgap | The improvement I'm asking for |
|---|---|---|
| The Monitor/channel path silently dies on compaction/restart, so a signal arrives and nothing wakes | When I notice, I re-arm it by hand | A durable channel/Monitor lifecycle — survive compaction/restart (auto-restore), or at least emit an event on death so re-arming can be automatic |
| To guard against that silent death, I keep a separate polling loop running until 21:00, wasting tokens and context | Accept the waste and keep polling | A durable push would let me drop the polling entirely |
| Slack/Linear signals can't reach a running session (official Slack spawns) | Hand-wire it with the Monitor tool + local automation | A Slack/Linear channel (or an easy path to build a durable custom channel) |

What the request actually is: not a brand-new capability from scratch, but to extend the Channels feature you already have (the right direction) to (1) Slack/Linear and (2) a durable lifecycle that survives compaction/restart.

For safety, two things alongside (some of which Channels already addresses): provenance — external-signal input visibly distinguished from local user input; approval preservation — a delivered signal must never equal execution permission; normal approvals, tool permissions, and escalation stay in force.

How I validated it, and the results

• Run across several of my own machines, at real business scale, over many days. It has produced actually-deployed applications, not demos. Claude <-> Codex cross-review runs as a real pipeline.
• So "waking a running session from a signal" is not hypothetical — it's already load-bearing, and its single weak point is the durability and Slack/Linear connection above.

On legitimacy, and what I am (and am not) relying on

I'm not relying on any undocumented hack. The monitoring is Claude Code's own official Monitor tool; for scheduling I use session-scoped scheduling (/loop, scheduled tasks) as a fallback; the only thing I built around them is ordinary local automation that surfaces an external signal to the right seat. Everything runs on official apps, my own paid subscription, and my own machines.
To be precise about what is and isn't automated: I automate the delivery of a routing signal — the same instruction I would otherwise type by hand, through documented Claude Code surfaces where available — not execution authority. Normal approvals, tool permissions, and my escalation policy stay in force; a delivered signal is context or a request, never permission to act. I'm not trying to bypass usage limits or billing. If any part of this is unsupported or inappropriate, tell me and I'll stop and use whatever supported path exists.

Related issues and features

• Channels (official docs, research preview) — the closest official feature; this request is the durability + Slack/Linear gap on top of it.
• Remote Control (#33041 and others) — manual, human/mobile ingress into a running session (with disconnect/staleness problems).
• Slack-triggered sessions (#63646) — automated trigger runs, but a fresh session spawn, not a wake of my already-running local session.
• Claude Desktop session killed by lock alone (#72851) — a real instance of the durability fragility.
• Human-paced vs autonomous billing/policy distinction (#59841) — legitimacy context.

More non-developer domain operators will end up here. If Channels supports Slack/Linear and gains a durable lifecycle that survives compaction/restart, none of us has to reinvent the fragile wiring.