[Question] Should /monitor, /agent, bridges survive REPL exit?

[mxh1999]

Hi, following up on #44 — after the prompts/ refactor I started looking at direction (3) "stronger autonomy on /monitor /worker /agent" and noticed a lifecycle question I'd like to align on before writing any code.

Several features feel like "always-on background services" to users, but they run as daemon threads inside the REPL process, so closing the REPL kills them silently:

• /monitor subscribe ... --schedule daily --telegram then /exit → scheduler thread dies; daily digest never arrives until REPL is reopened
• /agent start paper_writer over SSH, connection drops → agent_runner thread dies; in-memory AgentState.messages is lost (only iteration summaries survive in ~/.cheetahclaws/agents/<name>/log.jsonl)
• /telegram <token> <chat_id> then close laptop → bot stops responding to phone messages
• /proactive 5m then /exit → sentinel dies

tmux / nohup workarounds exist but I'm not sure the "personal AI assistant" positioning can assume users know to use them.

The good news is most of the daemon-shaped infrastructure is already there — session_store.py (SQLite + FTS5), health.py (/healthz /readyz /metrics), jobs.py, monitor/scheduler.py, quota.py, circuit_breaker.py. The gap looks like just the process model.

Two questions before I draft anything:

1. Is this a real product issue you want to address in the next few months, or is "REPL is everything" intentional for now?
2. If we should solve it, does the (still in progress) web UI direction prefer a headless cheetahclaws serve that REPL/web/bridges all connect to (opencode-style), or a detached daemon process that owns the long-running services with REPL staying a CLI client?

Happy to write up a phased plan once direction is clear.

Thanks!

[KevRojo]

I fix that, im gonna share the code on this issue tomorrow

Also gonna share the webserver

To chat with Falcon via localhost:5000

Hmm also the bash sandbox

Hmm my themes module

My claude-code integration (not api key needed)

My skill hub more than 850 skills Anthropic included

Cant make my repo public yet but im gonna extract some good features from him and give it to cheetah ❤️

[KevRojo]

Also let me know if you guys are thinking on some Gui, i can help with that too im making one for mine

[chauncygu]

Thanks @mxh1999 and @KevRojo, I really appreciate both of your contributions here.

@mxh1999, this is a very important product/lifecycle question. I agree that for features like /monitor, /agent, Telegram bridges, proactive mode, and schedulers, users will naturally expect them to survive REPL exit, SSH disconnects, or laptop sleep/restart when possible. So yes, I think this is a real product issue rather than just an implementation detail. The “REPL is everything” model is simple and useful for early development, but for CheetahClaws to become a reliable personal AI assistant / agent infrastructure, we should move toward a more persistent process model.

My current preference is a phased direction:

1. Short term: document the current behavior clearly and avoid silent failure where possible.
2. Medium term: introduce a headless cheetahclaws serve process that owns long-running services such as monitor, agent runners, bridges, scheduler, health endpoints, and job state.
3. Long term: make REPL, Web UI, Telegram, and future bridges clients of the same backend service, so we have one shared runtime instead of many disconnected entry points.

@KevRojo, thank you as well. The web server, GUI work, sandbox ideas, themes module, Claude Code integration, and skill hub all sound very valuable. Please feel free to share whatever pieces you are comfortable extracting. We would be very happy to review and integrate useful components into CheetahClaws.

I think this issue closely aligns with the broader roadmap: moving CheetahClaws from a terminal-first tool to a persistent, extensible agent system.

[mxh1999]

Thanks @chauncygu for the clear phasing. Following up with a concrete design proposal so we have something to react to.

What moves into the daemon

Anything users expect to keep running across REPL exits:

• /monitor scheduler
• /agent runners
• /proactive watcher
• Telegram / Slack / WeChat bridges
• Jobs, quota counters, circuit breakers
• The session store (SQLite, sole writer)
• The agent.run() loop itself

What stays in the REPL: argparse, the input prompt, terminal rendering, voice capture — anything that has to sit next to the keyboard and screen.

REPL stops being the agent host

Today the REPL process is the agent — it owns agent.run(), the bridges hang off it, and exiting it kills everything. After this change the REPL becomes one of several clients of the daemon, alongside the Web UI and the messaging bridges. It sends user input to the daemon and renders the event stream coming back. When no daemon is running, the REPL falls back to today's in-process behavior, so nothing breaks for users who never opt in.

Knock-on effects worth flagging

Bridges become daemon-owned. Today bridges call agent.run directly and pass state through RuntimeContext. After the change, an incoming Telegram/Slack/WeChat message goes through the same code path as REPL input. "User input from REPL", "user input from Web UI", "user input from a bridge" all become the same thing to the daemon. This is the biggest design decision in this proposal and the one I'd most like a maintainer call on before I write any migration code.

Permission requests become asynchronous. agent.run already yields PermissionRequest. Today the REPL blocks on input() to answer it. In a daemon there may be no terminal connected, so requests get pushed to whichever clients are listening (REPL, Web, bridges) and the first answer wins. This pulls in a new "unattended" permission mode for daemon-only operation, with whitelists and per-iteration cost caps.

Cost guardrails need safe defaults. quota.py defaults to unlimited today, which is fine for interactive use but unsafe for something running 7×24h. The daemon will ship with conservative budget defaults (overridable); the REPL keeps today's behavior.

Web UI relationship. This proposal only defines the API the UI will consume — the UI itself is a separate proposal. Same for any GUI client work; once the API is stable, any client can target it without coupling to this proposal.

No user-visible breakage until the final phase. The plan is: build the daemon foundation → migrate services into it one PR at a time → make REPL a client → flip defaults. Until the last step, users who don't run cheetahclaws serve see no change.

Explicit non-goals

• Multi-user auth, clustering, multi-host
• Web UI implementation
• Replacing the agent core, tool registry, MCP, or skills
• GUI clients, themes, sandbox redesign — decoupled from this proposal

Decisions I'd like before starting

1. Bridges-into-daemon (the big one) — go / no-go on the ownership reversal above. The rest of this proposal still works without it, but the migration looks very different.
2. When to commit to a stable client API. External clients (Web UI, future GUI work) need this frozen at some point — my preference is to keep it experimental through the migration and freeze at the default-flip.
3. Anything in "what moves into the daemon" you'd rather keep in REPL, or vice versa.

Once these are settled I can open the foundation PR (additive only, no behavior change for existing users).

[chauncygu]

Thanks @mxh1999, the phasing is well-scoped. Decisions on the three you asked for:

1. Bridges-into-daemon: go. Without the ownership reversal the rest of the proposal doesn't deliver the user-visible win (Telegram surviving REPL exit is the headline feature). Make this part of the foundation work, not a later phase.

2. API stability: keep experimental through migration, but cut an RC one minor version before the default flip, not at the flip itself. External clients (Web UI, GUI work) need a predictable window where breaking changes stop. "Frozen the day defaults change" is too late for them to ship against.

3. What moves / stays: your split is right. Two notes:

• Voice capture stays REPL-side (local audio device).
• Agent runners: please consider subprocess-per-agent rather than threads in the daemon. One leaking/crashing runner shouldn't take down the scheduler and bridges with it.

Before the foundation PR, I'd like a short design note covering three things , these will drive every later PR and are cheaper to debate on a doc than in code review:

• IPC: protocol + transport (suggest Unix socket + JSON-RPC, events over SSE; optional --listen tcp:// with token).
• Permission routing: each PermissionRequest carries an originator; answer routes back to that client by default. "First answer wins" across all subscribers is racy and lets a phone bridge approve something the REPL user didn't ask for.
• Local auth: even with multi-user as a non-goal, the socket needs file-permission protection and TCP needs a token. This is a security boundary, not a multi-user feature.

Cost guardrails with conservative daemon defaults: agreed, ship those with the foundation.

Once the design note is up, foundation PR is good to go.

[mxh1999]

Design note opened as #74 for line-by-line review. Three open questions flagged inline (HTTP framing, agent_runner originator class, audit log default for Unix socket); once those are resolved I'll move to the foundation PR.

[chauncygu]

Hi @mxh1999, Thanks for your great contributions. I replied to you in #74 for more details.

If it helps or if you have any questions, I'd be happy to discuss. Just say the word.

[chauncygu]

Hi @mxh1999 — heads up before you start the foundation PR. I put up a spike that validates the contract from RFC #74 end-to-end so we have something runnable to push back on (or build on) before you sink time into the real implementation, see this branch: https://github.com/SafeRL-Lab/cheetahclaws/tree/feature/daemon-spike:

What the spike does cover (the ✓ rows of the review matrix from your doc PR):

• ThreadedHTTPServer + ThreadedUnixServer with a bumped request_queue_size
• 15s SSE heartbeat
• client_id mint / persist (~/.cheetahclaws/clients/<kind>.id) / resume
• Cheetahclaws-Api-Version: 0 header → 426 on mismatch
• In-memory ring buffer with gap event on overflow
• Audit log default-on for both transports (Unix + TCP)
• Linux SO_PEERCRED peer-cred + bearer-token auth + brute-force throttle
• Originator-only permission.answer (HTTP 403 / -32001 to non-originators)
• 30 min interactive timeout + permission.refresh_timeout RPC

13 pytest cases, all green. Full coverage matrix and a runnable Alice/Bob originator-routing demo in https://github.com/SafeRL-Lab/cheetahclaws/blob/feature/daemon-spike/docs/RFC/0001-spike-notes.md.

What the spike deliberately does not cover — yours to design:

• agent.run integration (session.send is a placeholder echo.ping only)
• Bridges migration (Telegram / Slack / WeChat)
• SQLite daemon_events table (spike uses an in-memory ring)
• Cost guardrails / quota
• Subprocess-per-agent runner
• macOS peer-cred (TODO(macos) left in cc_daemon/auth.py)
• /metrics (so no redaction story yet)

Suggested division of labor: keep the spike's server.py, auth.py, originator.py, rpc.py more or less as-is (they encode the contract); rip out and rewrite methods.py and permission.py against the real agent.run flow; swap events.py's ring for the SQLite schema. Anything not on that list is fair game.

This is reference scaffolding, not a takeover. Pinging you early so you can flag anything in the spike's contract surface that doesn't match what you had in mind, before either of us writes more code against it.

[mxh1999]

Foundation PR opened as #80 — first half of the roadmap (F-1: discovery + system methods + daemon CLI + health wiring + subprocess e2e), built on top of @chauncygu's spike branch. Implementation approach + the auth-by-default change for /healthz called out in the PR body — would appreciate your review on whether the spike-as-contract + glue-on-top split is the shape you want before F-2 / F-3 land on top.