jeo-code 0.7.35 → 0.7.37

package/CHANGELOG.md

@@ -6,6 +6,34 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 The README mirrors the latest 5 entries — regenerate with `bun run changelog:sync`.
 
+## [0.7.37] - 2026-07-05
+_Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, scoped to jeo's subagent surface only — no forum topics, no inline keyboards, no image attachments; see CHANGELOG 0.7.34 for what jeo intentionally does not replicate from gjc's full notification stack)._
+
+### Added
+- **`jeo notify setup|status`** — pairs a Telegram bot (BotFather token + `getMe` verification, then either an explicit `--chat-id` or an interactive `getUpdates` poll for a private DM) and persists `notifications.enabled`/`notifications.telegram.{botToken,chatId}` in `~/.jeo/config.json`. `status` prints a masked token, the paired chat id, and the daemon's running state.
+- **`jeo daemon status|start|stop|reload`** — manages a singleton background daemon process (`src/agent/notify/daemon-control.ts`): a pid+startedAt lock file at `~/.jeo/notifications/daemon.lock` enforces one owner (Telegram allows only one `getUpdates` long-poll per bot token), `start` self-invokes `jeo notify-daemon-run` detached (mirrors `memory.ts`'s `distillInvocation`/`spawnDetachedDistill` pattern) and refuses early with a clear message when notifications aren't configured yet, `stop` SIGTERMs the owner and waits for exit, `reload` is stop+start.
+- **`src/agent/notify/session-endpoint.ts`** — a per-turn, loopback-only (`127.0.0.1`, random port) WebSocket server exposing ONE `SubagentRegistry` for remote monitoring/control: publishes a token-authed discovery file, pushes a `snapshot` frame on connect and on any subagent-list change, and applies inbound `steer`/`cancel`/`list` requests to the SAME registry instance the `task`/`subagent` tools use. Wired in lazily and best-effort from `task-tool.ts`'s `task {detached:true}` path (`ensureSessionNotifyEndpoint`, a no-op unless `notifications.enabled`) and torn down at the turn boundary from `launch.ts`'s `finally` block (`stopSessionNotifyEndpoint`), symmetric with `subagentRegistry.cancelAll()`.
+- **`src/agent/notify/telegram-daemon.ts`** — the managed daemon: scans `~/.jeo/notifications/sessions/*.json` for live sessions (deletes stale dead-pid discovery files), connects a WebSocket to each, sends a Telegram push on subagent state EDGES only (started → a terminal state — never a re-report of an unchanged status), and long-polls Telegram `getUpdates` to dispatch `/subagents`, `/steer <sessionId> <subagentId> <message>`, `/cancel <sessionId> <subagentId>`, and `/help` back into the matching session over its WebSocket (request/ack round-trip with a 3s timeout).
+- **`src/agent/notify/telegram-api.ts`** — a minimal, injectable-`fetch` Telegram Bot API client (`getMe`/`sendMessage`/`getUpdates`) plus `maskToken` (first 4 chars + length, gjc `gjc notify status` masking parity).
+
+### Verified
+- `bun run typecheck` clean; `bun test` 2368 pass / 0 fail, including new suites `notify-paths`, `notify-telegram-api`, `notify-session-endpoint` (real `Bun.serve` + real `WebSocket` client, incl. wrong-token rejection and a real `SubagentRegistry` steer/cancel round-trip), `notify-telegram-daemon` (pure diff/format/parse helpers + a fake-WebSocket/fake-`TelegramApi` `TelegramDaemon`), `notify-daemon-control` (lock singleton refusal against a real live child pid, stale-lock reclaim against a real exited pid, `startDaemon`/`stopDaemon`/`reloadDaemon` lifecycle), `notify-command` and `daemon-command` (CLI layer).
+- Manual end-to-end smoke test: `jeo daemon start` with `notifications.enabled`+fake token/chat id in a scratch `JEO_CONFIG_DIR` really spawns `notify-daemon-run` detached, `jeo daemon status` reports `running (pid …)`, `jeo daemon stop` SIGTERMs it and `jeo daemon status` reports `stopped` with no lingering process (verified via `ps aux`). A first manual run against unconfigured notifications surfaced a real race (the daemon exits almost immediately, racing `startDaemon`'s 2s readiness poll) — fixed by checking `isNotifyConfigured()` BEFORE spawning instead of after.
+
+
+## [0.7.36] - 2026-07-04
+_Removes two specific guardrails per explicit user direction: `jeo approve`'s human-only identity gate (the agent can now approve its own reviewed `jeo ralplan` plan) and the disk-staleness write/edit clobber guard (a write/edit no longer refuses just because the file changed on disk since the last read). Both removals were scoped narrowly after enumerating every guardrail in the codebase — the catastrophic-command hard block (`rm -rf /`, fork bombs, raw-disk `dd`/`mkfs`), the read-only subagent role tool gating, the deep-interview mutation lock, and the blind-edit (never-read-this-session) guard are all UNCHANGED._
+
+### Removed
+- **The `jeo approve` human-only identity gate.** Previously `ralplanState.approved` could only be flipped by a human running `jeo approve <plan-path>` in their own terminal — there was no way for the agent itself to approve a plan it had just drafted and had reviewed pass consensus. `src/commands/approve.ts`'s validation logic (schema shape, known subagent roles, persisted `[OKAY]` consensus verdict, hash-vs-consensus match) is extracted into an exported `approvePlan()` core — unchanged and still enforced no matter who calls it — shared by the `jeo approve` CLI (`runApproveCommand`, now a thin wrapper) and a new agent-facing `approve` tool (`src/agent/approve-tool.ts`). Wired into `launch.ts` the same way as `goal`/`irc` (main interactive session only, not part of `DEFAULT_TOOLS`/`subagentToolset`, so spawned subagents still cannot approve plans).
+- **The disk-staleness write/edit clobber guard (`src/agent/tools.ts`'s `staleReadError`).** A write/edit against a file that changed on disk since the agent's last read is no longer rejected — the agent's write always wins now, even over a concurrent formatter/user/other-agent edit. The distinct blind-edit guard is UNCHANGED: a no-anchor line-range `edit` still requires having read the file at least once this session (`readThisSession`/`markRead`, the presence-only successor to the removed staleness-comparison snapshot map).
+
+### Verified
+- `bunx tsc -p tsconfig.json --noEmit` clean.
+- New `test/approve-tool.test.ts` (explicit/defaulted planPath, missing-state error, the shared content gate still refusing an unreviewed/hash-mismatched plan through the tool, idempotent re-approval) and `test/launch-approve-wiring.test.ts` (source-text wiring check, mirrors `engine-computer-wiring.test.ts`'s pattern for module-local closures).
+- `test/edit-freshness.test.ts` updated: the two external-change scenarios now assert the write/edit SUCCEEDS and overwrites, instead of asserting rejection; the never-read-this-session and SEARCH-mismatch-recovery cases (a different guard) are untouched and still pass.
+- `test/approve.test.ts` (CLI-level, all 6 validation/idempotency branches) passes unchanged against the refactored `approvePlan()` core.
+
 ## [0.7.35] - 2026-07-04
 _`jeo team` now runs every plan step through the SAME subagent execution core as the `task`/`subagent` tools, and gains gjc-style concurrent workers: a plan can mark a contiguous run of independent steps to execute in parallel, each isolated in its own git worktree, merged back in order._
 

package/README.ja.md

@@ -207,11 +207,11 @@ CI は `.github/workflows/npm-publish.yml` で公開します — GitHub リリ
 ## 変更履歴 (Changelog)
 
 <!-- CHANGELOG:START (auto-generated from CHANGELOG.md — run `bun run changelog:sync`) -->
+- **[0.7.37]** (2026-07-05) — Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, scoped to jeo's subagent surface only — no forum topics, no inline keyboards, no image attachments; see CHANGELOG 0.7.34 for what jeo intentionally does not replicate from gjc's full notification stack).
+- **[0.7.36]** (2026-07-04) — Removes two specific guardrails per explicit user direction: `jeo approve`'s human-only identity gate (the agent can now approve its own reviewed `jeo ralplan` plan) and the disk-staleness write/edit clobber guard (a write/edit no longer refuses just because the file changed on disk since the last read). Both removals were scoped narrowly after enumerating every guardrail in the codebase — the catastrophic-command hard block (`rm -rf /`, fork bombs, raw-disk `dd`/`mkfs`), the read-only subagent role tool gating, the deep-interview mutation lock, and the blind-edit (never-read-this-session) guard are all UNCHANGED.
 - **[0.7.35]** (2026-07-04) — `jeo team` now runs every plan step through the SAME subagent execution core as the `task`/`subagent` tools, and gains gjc-style concurrent workers: a plan can mark a contiguous run of independent steps to execute in parallel, each isolated in its own git worktree, merged back in order.
 - **[0.7.34]** (2026-07-04) — gajae-code 0.8.0/0.8.1 parity audit: closes a real cross-provider lone-surrogate JSON bug and makes turn-boundary compaction Esc-cancellable; the rest of gjc's 0.8.x release (Telegram daemon, ACP, cmux, coordinator MCP, tool-discovery-mode, an internal paged transcript viewport) is gjc-specific architecture jeo intentionally does not replicate, or was already-equivalent (confirmed by a 4-way parallel audit: ast_grep formatting, session-picker empty-filter clamping, PageUp/PageDown).
 - **[0.7.33]** (2026-07-04) — Adds `browser` — headless Chromium automation (gjc `browser` parity) — completing the gjc tool-surface parity pass started in 0.7.32.
-- **[0.7.32]** (2026-07-03) — gjc tool-surface parity — ast_grep/ast_edit, lsp/lsp_rename, debug, irc, job, and goal tools — plus a `launch.ts` slash-command refactor and four agent-loop guardrail hardenings (destructive-bash denylist, spawn-gate justification quality check, done-verification abuse guard, and a blind unanchored line-range-edit guard).
-- **[0.7.31]** (2026-07-03) — Three-round speed & memory pass across streaming, memory retrieval, and the TUI render loop (O(n²) → O(n) in several hot paths), a deep-interview repeat-question loop guard, and gajae-code managed-tmux launch sizing parity.
 
 See [CHANGELOG.md](CHANGELOG.md) for the full history.
 <!-- CHANGELOG:END -->

package/README.ko.md

@@ -207,11 +207,11 @@ CI는 `.github/workflows/npm-publish.yml`로 배포합니다 — GitHub 릴리
 ## 변경 이력 (Changelog)
 
 <!-- CHANGELOG:START (auto-generated from CHANGELOG.md — run `bun run changelog:sync`) -->
+- **[0.7.37]** (2026-07-05) — Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, scoped to jeo's subagent surface only — no forum topics, no inline keyboards, no image attachments; see CHANGELOG 0.7.34 for what jeo intentionally does not replicate from gjc's full notification stack).
+- **[0.7.36]** (2026-07-04) — Removes two specific guardrails per explicit user direction: `jeo approve`'s human-only identity gate (the agent can now approve its own reviewed `jeo ralplan` plan) and the disk-staleness write/edit clobber guard (a write/edit no longer refuses just because the file changed on disk since the last read). Both removals were scoped narrowly after enumerating every guardrail in the codebase — the catastrophic-command hard block (`rm -rf /`, fork bombs, raw-disk `dd`/`mkfs`), the read-only subagent role tool gating, the deep-interview mutation lock, and the blind-edit (never-read-this-session) guard are all UNCHANGED.
 - **[0.7.35]** (2026-07-04) — `jeo team` now runs every plan step through the SAME subagent execution core as the `task`/`subagent` tools, and gains gjc-style concurrent workers: a plan can mark a contiguous run of independent steps to execute in parallel, each isolated in its own git worktree, merged back in order.
 - **[0.7.34]** (2026-07-04) — gajae-code 0.8.0/0.8.1 parity audit: closes a real cross-provider lone-surrogate JSON bug and makes turn-boundary compaction Esc-cancellable; the rest of gjc's 0.8.x release (Telegram daemon, ACP, cmux, coordinator MCP, tool-discovery-mode, an internal paged transcript viewport) is gjc-specific architecture jeo intentionally does not replicate, or was already-equivalent (confirmed by a 4-way parallel audit: ast_grep formatting, session-picker empty-filter clamping, PageUp/PageDown).
 - **[0.7.33]** (2026-07-04) — Adds `browser` — headless Chromium automation (gjc `browser` parity) — completing the gjc tool-surface parity pass started in 0.7.32.
-- **[0.7.32]** (2026-07-03) — gjc tool-surface parity — ast_grep/ast_edit, lsp/lsp_rename, debug, irc, job, and goal tools — plus a `launch.ts` slash-command refactor and four agent-loop guardrail hardenings (destructive-bash denylist, spawn-gate justification quality check, done-verification abuse guard, and a blind unanchored line-range-edit guard).
-- **[0.7.31]** (2026-07-03) — Three-round speed & memory pass across streaming, memory retrieval, and the TUI render loop (O(n²) → O(n) in several hot paths), a deep-interview repeat-question loop guard, and gajae-code managed-tmux launch sizing parity.
 
 See [CHANGELOG.md](CHANGELOG.md) for the full history.
 <!-- CHANGELOG:END -->

package/README.md

@@ -234,11 +234,11 @@ Huge thanks to [gajae-code](https://github.com/Yeachan-Heo/gajae-code) for the i
 ## Changelog
 
 <!-- CHANGELOG:START (auto-generated from CHANGELOG.md — run `bun run changelog:sync`) -->
+- **[0.7.37]** (2026-07-05) — Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, scoped to jeo's subagent surface only — no forum topics, no inline keyboards, no image attachments; see CHANGELOG 0.7.34 for what jeo intentionally does not replicate from gjc's full notification stack).
+- **[0.7.36]** (2026-07-04) — Removes two specific guardrails per explicit user direction: `jeo approve`'s human-only identity gate (the agent can now approve its own reviewed `jeo ralplan` plan) and the disk-staleness write/edit clobber guard (a write/edit no longer refuses just because the file changed on disk since the last read). Both removals were scoped narrowly after enumerating every guardrail in the codebase — the catastrophic-command hard block (`rm -rf /`, fork bombs, raw-disk `dd`/`mkfs`), the read-only subagent role tool gating, the deep-interview mutation lock, and the blind-edit (never-read-this-session) guard are all UNCHANGED.
 - **[0.7.35]** (2026-07-04) — `jeo team` now runs every plan step through the SAME subagent execution core as the `task`/`subagent` tools, and gains gjc-style concurrent workers: a plan can mark a contiguous run of independent steps to execute in parallel, each isolated in its own git worktree, merged back in order.
 - **[0.7.34]** (2026-07-04) — gajae-code 0.8.0/0.8.1 parity audit: closes a real cross-provider lone-surrogate JSON bug and makes turn-boundary compaction Esc-cancellable; the rest of gjc's 0.8.x release (Telegram daemon, ACP, cmux, coordinator MCP, tool-discovery-mode, an internal paged transcript viewport) is gjc-specific architecture jeo intentionally does not replicate, or was already-equivalent (confirmed by a 4-way parallel audit: ast_grep formatting, session-picker empty-filter clamping, PageUp/PageDown).
 - **[0.7.33]** (2026-07-04) — Adds `browser` — headless Chromium automation (gjc `browser` parity) — completing the gjc tool-surface parity pass started in 0.7.32.
-- **[0.7.32]** (2026-07-03) — gjc tool-surface parity — ast_grep/ast_edit, lsp/lsp_rename, debug, irc, job, and goal tools — plus a `launch.ts` slash-command refactor and four agent-loop guardrail hardenings (destructive-bash denylist, spawn-gate justification quality check, done-verification abuse guard, and a blind unanchored line-range-edit guard).
-- **[0.7.31]** (2026-07-03) — Three-round speed & memory pass across streaming, memory retrieval, and the TUI render loop (O(n²) → O(n) in several hot paths), a deep-interview repeat-question loop guard, and gajae-code managed-tmux launch sizing parity.
 
 See [CHANGELOG.md](CHANGELOG.md) for the full history.
 <!-- CHANGELOG:END -->

package/README.zh.md

@@ -207,11 +207,11 @@ CI 通过 `.github/workflows/npm-publish.yml` 发布 — GitHub 发布 release
 ## 更新日志 (Changelog)
 
 <!-- CHANGELOG:START (auto-generated from CHANGELOG.md — run `bun run changelog:sync`) -->
+- **[0.7.37]** (2026-07-05) — Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, scoped to jeo's subagent surface only — no forum topics, no inline keyboards, no image attachments; see CHANGELOG 0.7.34 for what jeo intentionally does not replicate from gjc's full notification stack).
+- **[0.7.36]** (2026-07-04) — Removes two specific guardrails per explicit user direction: `jeo approve`'s human-only identity gate (the agent can now approve its own reviewed `jeo ralplan` plan) and the disk-staleness write/edit clobber guard (a write/edit no longer refuses just because the file changed on disk since the last read). Both removals were scoped narrowly after enumerating every guardrail in the codebase — the catastrophic-command hard block (`rm -rf /`, fork bombs, raw-disk `dd`/`mkfs`), the read-only subagent role tool gating, the deep-interview mutation lock, and the blind-edit (never-read-this-session) guard are all UNCHANGED.
 - **[0.7.35]** (2026-07-04) — `jeo team` now runs every plan step through the SAME subagent execution core as the `task`/`subagent` tools, and gains gjc-style concurrent workers: a plan can mark a contiguous run of independent steps to execute in parallel, each isolated in its own git worktree, merged back in order.
 - **[0.7.34]** (2026-07-04) — gajae-code 0.8.0/0.8.1 parity audit: closes a real cross-provider lone-surrogate JSON bug and makes turn-boundary compaction Esc-cancellable; the rest of gjc's 0.8.x release (Telegram daemon, ACP, cmux, coordinator MCP, tool-discovery-mode, an internal paged transcript viewport) is gjc-specific architecture jeo intentionally does not replicate, or was already-equivalent (confirmed by a 4-way parallel audit: ast_grep formatting, session-picker empty-filter clamping, PageUp/PageDown).
 - **[0.7.33]** (2026-07-04) — Adds `browser` — headless Chromium automation (gjc `browser` parity) — completing the gjc tool-surface parity pass started in 0.7.32.
-- **[0.7.32]** (2026-07-03) — gjc tool-surface parity — ast_grep/ast_edit, lsp/lsp_rename, debug, irc, job, and goal tools — plus a `launch.ts` slash-command refactor and four agent-loop guardrail hardenings (destructive-bash denylist, spawn-gate justification quality check, done-verification abuse guard, and a blind unanchored line-range-edit guard).
-- **[0.7.31]** (2026-07-03) — Three-round speed & memory pass across streaming, memory retrieval, and the TUI render loop (O(n²) → O(n) in several hot paths), a deep-interview repeat-question loop guard, and gajae-code managed-tmux launch sizing parity.
 
 See [CHANGELOG.md](CHANGELOG.md) for the full history.
 <!-- CHANGELOG:END -->

package/package.json

@@ -1,6 +1,7 @@
 {
   "name": "jeo-code",
-  "version": "0.7.35",
+  "version": "0.7.37",
+
 
   "description": "Clean, highly optimized AI coding agent using spec-first loop",
   "type": "module",

package/src/agent/AGENTS.md

@@ -43,6 +43,7 @@ The core runtime loop, tool registry, session management, and state persistence
 | `state.ts` | File-backed state and session persistence (`.jeo/state/`) |
 | `step-budget.ts` | gjc-style flexible step budgeting: progress-scored extensions, hard cap, fail-fast |
 | `irc-tool.ts` | `irc` tool — parent/peer live messaging into running DETACHED subagents (list peers, send to one id or "all"); built entirely on `SubagentRegistry.steer()`, gjc `irc` parity |
+| `approve-tool.ts` | `approve` tool — lets the agent flip a `jeo ralplan` plan's `approved` flag itself (wraps `src/commands/approve.ts`'s `approvePlan` content gate: schema shape, known roles, persisted [OKAY] consensus, hash-vs-consensus match). 2026-07: the prior human-only identity gate (only `jeo approve` run by a human could approve) was removed per explicit user direction; launch.ts-only (main interactive session), not part of `DEFAULT_TOOLS`/`subagentToolset`, same as `goal`/`irc` |
 | `job-registry.ts` | In-process registry for BACKGROUND shell processes spawned via `job {action:"start"}` — real parallel OS processes (not just concurrent JS), bounded output buffer, list/tail/awaitIds/cancel, gjc `job`/async-bash parity |
 | `job-tool.ts` | `job` control tool — start/list/tail/await/cancel background shell processes tracked by `job-registry.ts` |
 | `subagent-registry.ts` | Brief description of purpose |
@@ -52,13 +53,15 @@ The core runtime loop, tool registry, session management, and state persistence
 | `todo-tool.ts` | Brief description of purpose |
 | `tokenizer.ts` | Brief description of purpose |
 | `tool-output.ts` | Brief description of purpose |
-| `tools.ts` | Built-in tool definitions (bash, read, write, edit, etc.) |
+| `tools.ts` | Built-in tool definitions (bash, read, write, edit, etc.). 2026-07: the disk-staleness clobber guard (rejecting a write/edit when the file changed on disk since the agent's last read) was removed per explicit user direction — writes always win now. The distinct blind-edit guard (`readThisSession`/`markRead`: a no-anchor line-range `edit` still requires having read the file THIS session at least once) is unchanged |
 | `web-search.ts` | Brief description of purpose |
 
 ## Subdirectories
 | Directory | Purpose |
 |-----------|---------|
 | `dev/` | Developer-specific agent tooling and spec automation (see `dev/AGENTS.md`) |
+| `notify/` | Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, scoped to subagents) — session-endpoint loopback WebSocket, the managed daemon, daemon lifecycle control, path helpers, and a minimal Telegram Bot API client |
+
 
 ## For AI Agents
 

package/src/agent/approve-tool.ts

@@ -0,0 +1,42 @@
+/**
+ * `approve` tool — lets the agent itself flip a `jeo ralplan` plan's `approved`
+ * flag so `jeo team`/`jeo ultragoal` can execute it, wrapping the exact same
+ * content gate the `jeo approve` CLI command enforces (src/commands/approve.ts's
+ * `approvePlan`): schema shape, known subagent roles, a persisted [OKAY]
+ * consensus verdict, and a hash match against what the consensus critic
+ * reviewed. 2026-07: previously this flag could ONLY be flipped by a human
+ * running `jeo approve <path>` in their own terminal — that identity gate is
+ * removed per explicit user direction (gjc-style: the agent can act on its own
+ * plans). The plan-QUALITY gate above is unchanged and still refuses a
+ * schema-invalid, unreviewed, or post-review-edited plan no matter who calls it.
+ */
+import type { ToolHandler } from "./engine";
+import type { ToolResult } from "./tools";
+import { readWorkflowState } from "./state";
+import { approvePlan } from "../commands/approve";
+
+/** One-line protocol description appended to the launch system prompt. */
+export const APPROVE_TOOL_PROTOCOL_LINE =
+  `approve {planPath?} approves the active 'jeo ralplan' plan (planPath defaults to the active plan ` +
+  `from ralplan state when omitted) so 'jeo team'/'jeo ultragoal' can execute it next. Refuses a plan ` +
+  `that is schema-invalid, references an unknown role, lacks a persisted [OKAY] consensus verdict, or ` +
+  `was edited after the consensus critic reviewed it — same content gate as the 'jeo approve' CLI command.`;
+
+export function createApproveTool(): ToolHandler {
+  return async (args: Record<string, any>, cwd: string): Promise<ToolResult> => {
+    let planPath = typeof args.planPath === "string" ? args.planPath.trim() : "";
+    if (!planPath) {
+      const ralplanState = await readWorkflowState("ralplan", cwd);
+      planPath = ralplanState?.plan_path ?? "";
+    }
+    if (!planPath) {
+      return {
+        success: false,
+        output: "",
+        error: `approve requires a 'planPath' (no active ralplan plan found to default to). Run 'jeo ralplan' first, or pass the plan path explicitly.`,
+      };
+    }
+    const { ok, message } = await approvePlan(planPath, cwd);
+    return ok ? { success: true, output: message } : { success: false, output: "", error: message };
+  };
+}

package/src/agent/config-schema.ts

@@ -84,6 +84,23 @@ export const ConfigSchema = z
         onAsk: z.boolean().optional(),
       })
       .optional(),
+    /** Remote subagent visibility/control over Telegram (gjc Telegram-daemon
+     *  parity, scoped to subagents — see `src/agent/notify/`). `enabled` is the
+     *  master toggle; a session only starts publishing its loopback endpoint
+     *  when this is true, and `jeo notify-daemon-run` refuses to poll Telegram
+     *  without a stored botToken + chatId. */
+    notifications: z
+      .object({
+        enabled: z.boolean().optional(),
+        telegram: z
+          .object({
+            botToken: z.string().optional(),
+            chatId: z.string().optional(),
+          })
+          .optional(),
+      })
+      .optional(),
+
     /** Root path of the global llm-wiki vault, shared across every session
      *  regardless of project/cwd. A leading `~` is expanded; env `JEO_WIKI_ROOT`
      *  overrides. Consumed by `resolveWikiRoot` and injected into the prompt. */

package/src/agent/notify/AGENTS.md

@@ -0,0 +1,47 @@
+<!-- Parent: ../AGENTS.md -->
+<!-- Generated: 2026-07-05 -->
+
+# notify
+
+## Purpose
+Remote subagent visibility/control over Telegram (gjc Telegram-daemon parity, deliberately scoped to jeo's subagent surface only — no forum topics, inline keyboards, or image attachments; see root `CHANGELOG.md` 0.7.34 for what jeo intentionally does not replicate from gjc's full notification stack).
+
+## Key Files
+| File | Description |
+|------|-------------|
+| `paths.ts` | Path helpers under `<jeoHome>/notifications` (daemon lock/log, per-session discovery files) |
+| `telegram-api.ts` | Minimal, injectable-`fetch` Telegram Bot API client (`getMe`/`sendMessage`/`getUpdates`) + `maskToken` |
+| `session-endpoint.ts` | Per-turn, loopback-only WebSocket server exposing ONE `SubagentRegistry` (discovery file + `snapshot`/`steer`/`cancel`/`list` protocol); lazy `ensureSessionNotifyEndpoint`/`stopSessionNotifyEndpoint` wiring, no-op unless `notifications.enabled` |
+| `daemon-control.ts` | Daemon lifecycle: pid+startedAt lock singleton, `daemonInvocation` self-spawn argv (mirrors `memory.ts`'s `distillInvocation`), `startDaemon`/`stopDaemon`/`reloadDaemon`/`daemonStatus` |
+| `telegram-daemon.ts` | The managed daemon (`TelegramDaemon` class + `runNotifyDaemonForeground` CLI entrypoint): scans session discovery files, connects a WS per session, pushes Telegram messages on subagent status EDGES only, and dispatches inbound `/subagents`/`/steer`/`/cancel`/`/help` commands back over the matching session's WebSocket |
+
+## Subdirectories
+*(None)*
+
+## For AI Agents
+
+### Working In This Directory
+- The session-side WebSocket server MUST stay loopback-only (`127.0.0.1`); the daemon-to-Telegram hop is the only internet-facing part of this feature.
+- Every entrypoint here must stay a no-op (or refuse cleanly with a clear message) unless `notifications.enabled` + a stored bot token + chat id are all present — never assume the feature is configured.
+- `daemon-control.ts`'s singleton lock exists because Telegram allows only ONE `getUpdates` long-poll owner per bot token; never bypass it.
+
+### Testing Requirements
+- Prefer real `Bun.serve`/`WebSocket` for `session-endpoint.ts` tests (fast, no mocking needed) and injected fakes (`WebSocketImpl`, `TelegramApi`, `readdir`/`readFile`/`unlink`/`isPidAlive`) for `telegram-daemon.ts`/`daemon-control.ts`.
+- Any test touching `readGlobalConfig`/`saveConfigPatch` must isolate `JEO_CONFIG_DIR` to a temp directory (see `test/notify-daemon-control.test.ts`).
+
+### Common Patterns
+- Dependency injection for network/fs/time so daemon logic is unit-testable without a real bot token or real child processes.
+- Edge-triggered (not level-triggered) status reporting: a message is sent on a TRANSITION, never on every poll tick.
+
+## Dependencies
+
+### Internal
+- `../subagent-registry.ts` (`SubagentRegistry`, `SubagentRecord`).
+- `../state.ts` (`readGlobalConfig`/`saveConfigPatch` for `notifications` settings).
+- Consumed by `../task-tool.ts` (`ensureSessionNotifyEndpoint`), `../../commands/launch.ts` (`stopSessionNotifyEndpoint`), `../../commands/notify.ts`, `../../commands/daemon.ts`, and the hidden `notify-daemon-run` CLI entrypoint (`src/cli/runner.ts`).
+
+### External
+- Telegram Bot HTTP API (`https://api.telegram.org`) — the only outbound network call in this feature.
+- Bun's native `Bun.serve` (WebSocket server) and global `WebSocket` (client) — zero added dependencies.
+
+<!-- MANUAL: Any manually added notes below this line are preserved on regeneration -->

package/src/agent/notify/daemon-control.ts

@@ -0,0 +1,158 @@
+/**
+ * Daemon lifecycle control (gjc `daemon` command / `control-types.ts` parity,
+ * scoped to jeo's one daemon kind — telegram). A pid+startedAt lock file at
+ * `notifyDaemonLockPath()` enforces the singleton: Telegram allows only one
+ * `getUpdates` long-poll owner per bot token, so a second daemon process must
+ * refuse to start rather than race the first for updates (409 Conflict).
+ */
+import * as fs from "node:fs/promises";
+import * as fsSync from "node:fs";
+import * as path from "node:path";
+import { spawn as nodeSpawn } from "node:child_process";
+import { notifyDaemonLockPath, notifyDaemonLogPath, notifyDir } from "./paths";
+import { readGlobalConfig } from "../state";
+
+export interface DaemonLockInfo {
+  pid: number;
+  startedAt: number;
+}
+
+export function isPidAlive(pid: number): boolean {
+  try {
+    process.kill(pid, 0);
+    return true;
+  } catch {
+    return false;
+  }
+}
+
+export async function readDaemonLock(): Promise<DaemonLockInfo | undefined> {
+  try {
+    const raw = await fs.readFile(notifyDaemonLockPath(), "utf-8");
+    const parsed = JSON.parse(raw) as Partial<DaemonLockInfo>;
+    if (typeof parsed.pid !== "number" || typeof parsed.startedAt !== "number") return undefined;
+    return { pid: parsed.pid, startedAt: parsed.startedAt };
+  } catch {
+    return undefined;
+  }
+}
+
+/** Called by the daemon process itself on startup. Returns `undefined` when a
+ *  live owner already holds the lock (caller must exit without polling
+ *  Telegram); otherwise writes the lock and returns a `release()` closure. */
+export async function acquireDaemonLock(): Promise<{ release: () => Promise<void> } | undefined> {
+  await fs.mkdir(notifyDir(), { recursive: true, mode: 0o700 });
+  const existing = await readDaemonLock();
+  if (existing && existing.pid !== process.pid && isPidAlive(existing.pid)) return undefined;
+  const info: DaemonLockInfo = { pid: process.pid, startedAt: Date.now() };
+  await fs.writeFile(notifyDaemonLockPath(), JSON.stringify(info), { mode: 0o600 });
+  return {
+    release: async () => {
+      await fs.unlink(notifyDaemonLockPath()).catch(() => {});
+    },
+  };
+}
+
+export interface DaemonStatus {
+  /** `notifications.enabled` + a stored bot token + chat id are all present. */
+  configured: boolean;
+  running: boolean;
+  /** A lock file exists but its pid is dead — a previous daemon crashed without cleanup. */
+  stale: boolean;
+  pid?: number;
+  startedAt?: number;
+}
+
+export async function isNotifyConfigured(): Promise<boolean> {
+  const config = await readGlobalConfig();
+  return Boolean(config.notifications?.enabled && config.notifications.telegram?.botToken && config.notifications.telegram?.chatId);
+}
+
+export async function daemonStatus(): Promise<DaemonStatus> {
+  const [lock, configured] = await Promise.all([readDaemonLock(), isNotifyConfigured()]);
+  if (!lock) return { configured, running: false, stale: false };
+  const alive = isPidAlive(lock.pid);
+  return { configured, running: alive, stale: !alive, pid: lock.pid, startedAt: lock.startedAt };
+}
+
+/** Self-invocation argv for the daemon child (mirrors `memory.ts`'s
+ *  `distillInvocation` — compiled `/$bunfs` virtual path → run the binary
+ *  itself; `.ts`/`.js` source → through the runtime; anything else → directly). */
+export function daemonInvocation(argv1: string | undefined, execPath: string, cwd: string): string[] {
+  const entrypoint = argv1 ?? "";
+  let base: string[];
+  if (entrypoint === "" || entrypoint.startsWith("/$bunfs/") || entrypoint.startsWith("B:\\~BUN\\")) {
+    base = [execPath];
+  } else {
+    const resolved = path.isAbsolute(entrypoint) ? entrypoint : path.resolve(cwd, entrypoint);
+    base = /\.(ts|js|mjs)$/.test(entrypoint) ? [execPath, resolved] : [resolved];
+  }
+  return [...base, "notify-daemon-run"];
+}
+
+export type SpawnLike = (cmd: string[], cwd: string) => { unref(): void };
+
+const defaultSpawn: SpawnLike = (cmd, cwd) => {
+  fsSync.mkdirSync(notifyDir(), { recursive: true, mode: 0o700 });
+  const logFd = fsSync.openSync(notifyDaemonLogPath(), "a");
+  // node:child_process with detached:true (NOT Bun.spawn) — same rationale as
+  // memory.ts's spawnDetachedDistill: the child needs its own session/process
+  // group so a closing terminal/tmux pane does not kill it before it's ready.
+  const child = nodeSpawn(cmd[0]!, cmd.slice(1), { cwd, detached: true, stdio: ["ignore", logFd, logFd] });
+  return { unref: () => child.unref() };
+};
+
+async function waitFor(predicate: () => Promise<boolean>, timeoutMs: number, stepMs = 100): Promise<boolean> {
+  const deadline = Date.now() + timeoutMs;
+  while (Date.now() < deadline) {
+    if (await predicate()) return true;
+    await new Promise(r => setTimeout(r, stepMs));
+  }
+  return false;
+}
+
+export async function startDaemon(spawnImpl: SpawnLike = defaultSpawn): Promise<{ ok: boolean; pid?: number; message: string }> {
+  const existing = await readDaemonLock();
+  if (existing && isPidAlive(existing.pid)) {
+    return { ok: true, pid: existing.pid, message: `daemon already running (pid ${existing.pid})` };
+  }
+  // Check BEFORE spawning: an unconfigured daemon exits almost immediately (see
+  // `runNotifyDaemonForeground`), which races the readiness poll below and used to
+  // surface a misleading "did not report ready" — refuse early with a clear message.
+  if (!(await isNotifyConfigured())) {
+    return { ok: false, message: "notifications not configured — run 'jeo notify setup' first." };
+  }
+
+  const cmd = daemonInvocation(process.argv[1], process.execPath, process.cwd());
+  spawnImpl(cmd, process.cwd()).unref();
+  const ready = await waitFor(async () => {
+    const lock = await readDaemonLock();
+    return Boolean(lock && isPidAlive(lock.pid));
+  }, 2_000);
+  if (!ready) return { ok: false, message: `daemon did not report ready within 2s — check ${notifyDaemonLogPath()}` };
+  const lock = await readDaemonLock();
+  return { ok: true, pid: lock?.pid, message: `daemon started (pid ${lock?.pid})` };
+}
+
+export async function stopDaemon(): Promise<{ ok: boolean; message: string }> {
+  const lock = await readDaemonLock();
+  if (!lock || !isPidAlive(lock.pid)) {
+    await fs.unlink(notifyDaemonLockPath()).catch(() => {});
+    return { ok: true, message: "daemon was not running" };
+  }
+  try {
+    process.kill(lock.pid, "SIGTERM");
+  } catch (err) {
+    return { ok: false, message: `failed to signal pid ${lock.pid}: ${err instanceof Error ? err.message : String(err)}` };
+  }
+  const stopped = await waitFor(async () => !isPidAlive(lock.pid), 3_000);
+  if (!stopped) return { ok: false, message: `daemon (pid ${lock.pid}) did not exit within 3s` };
+  await fs.unlink(notifyDaemonLockPath()).catch(() => {});
+  return { ok: true, message: `daemon stopped (was pid ${lock.pid})` };
+}
+
+export async function reloadDaemon(spawnImpl: SpawnLike = defaultSpawn): Promise<{ ok: boolean; message: string }> {
+  const stopRes = await stopDaemon();
+  const startRes = await startDaemon(spawnImpl);
+  return { ok: startRes.ok, message: `${stopRes.message}; ${startRes.message}` };
+}

package/src/agent/notify/paths.ts

@@ -0,0 +1,41 @@
+/**
+ * Path helpers for the local Telegram notification daemon (gjc `notifications/`
+ * daemon-paths parity, scoped to jeo's single daemon kind). Everything lives under
+ * `<jeoHome>/notifications` — the SAME root `~/.jeo` (or `JEO_CONFIG_DIR`) used by
+ * `state.ts` for `config.json`, so one override env var moves both.
+ */
+import * as path from "node:path";
+import * as os from "node:os";
+import { jeoEnv } from "../../util/env";
+
+/** Root directory for all local jeo state, resolved at call time (not import
+ *  time) so a `JEO_CONFIG_DIR` override or runtime `HOME` change is honored. */
+export function jeoHomeDir(): string {
+  return jeoEnv("CONFIG_DIR") || path.join(os.homedir(), ".jeo");
+}
+
+/** Notification/daemon state root. */
+export function notifyDir(): string {
+  return path.join(jeoHomeDir(), "notifications");
+}
+
+/** Per-process session discovery files live here; the daemon scans this directory
+ *  for live sessions (`<sessionId>.json`), same shape as gjc's `readEndpoint`/
+ *  `scanRoots` (a loopback WebSocket URL + auth token per session). */
+export function notifySessionsDir(): string {
+  return path.join(notifyDir(), "sessions");
+}
+
+export function notifySessionEndpointPath(sessionId: string): string {
+  return path.join(notifySessionsDir(), `${sessionId}.json`);
+}
+
+/** Singleton lock for the daemon process (Telegram allows only one `getUpdates`
+ *  long-poll owner per bot token — gjc's rationale for a daemon lock/state file). */
+export function notifyDaemonLockPath(): string {
+  return path.join(notifyDir(), "daemon.lock");
+}
+
+export function notifyDaemonLogPath(): string {
+  return path.join(notifyDir(), "daemon.log");
+}