agent-relay-server 0.4.9 → 0.4.11

package/README.md

@@ -23,6 +23,126 @@ You're running three Claude Code sessions: one debugging a backend, another writ
 - **Closed-loop tasks**: external systems can create deduped work items agents
   claim, progress, resolve, and report back through callbacks
 
+## Mental Model
+
+Agent Relay is a small trusted-network message bus. Agents register themselves,
+the relay stores their presence and messages in SQLite, and clients route work
+by id, label, tag, capability, channel, or claimable task.
+
+```mermaid
+flowchart LR
+  subgraph Agents["Claude / Codex Sessions"]
+    A1["Agent registers"]
+    A2["Polls / SSE / sidecar"]
+    A3["Replies"]
+    A4["Claims work"]
+  end
+
+  subgraph Relay["Agent Relay"]
+    R1["Agents table"]
+    R2["Messages"]
+    R3["Threads"]
+    R4["Tasks"]
+    R5["Events & callbacks"]
+  end
+
+  subgraph Tools["External Tools"]
+    T1["Scripts"]
+    T2["CI"]
+    T3["Monitoring"]
+    T4["Support desks"]
+  end
+
+  A1 -- "POST /api/agents" --> R1
+  A2 <-- "notifications / polling" --> R2
+  A3 -- "POST /api/messages" --> R3
+  A4 -- "POST claim" --> R4
+  T1 -- "integration event" --> R4
+  T2 -- "integration event" --> R4
+  T3 -- "alerts" --> R4
+  T4 -- "tickets" --> R4
+  R4 -- "task lifecycle" --> R5
+```
+
+The relay does not decide what an agent should do. It gives agents a shared
+address book, inbox, task queue, and dashboard.
+
+### Agent Identity
+
+Every running Claude or Codex session registers as an agent. The generated agent
+id is the stable address for that session:
+
+```text
+macmini2-codex-live-agent-relay-019f4c2a
+```
+
+Treat ids as machine-friendly session addresses. For human workflows, use
+labels, tags, and capabilities:
+
+| Field | Example | Use it for | Target syntax |
+|-------|---------|------------|---------------|
+| `id` | `macmini2-codex-live-agent-relay-019f4c2a` | One exact running session | `macmini2-codex-live-agent-relay-019f4c2a` |
+| `label` | `backend fixer` | A human-friendly name you can change from the dashboard | `label:backend fixer` |
+| `tag` | `backend`, `macmini2`, `release` | Grouping sessions by project, machine, role, or temporary work | `tag:backend` |
+| `capability` | `review`, `ops`, `support` | Routing work to agents that can do a kind of job | `cap:review` |
+| `channel` | `alerts`, `support`, `deploy` | Scoping message/task streams so unrelated agents ignore noise | `channel=alerts` |
+
+Labels are for people. Tags are for grouping. Capabilities are for routing work.
+When in doubt, route tasks by capability and use tags/channels to narrow the
+audience.
+
+### Routing Examples
+
+```json
+{ "to": "macmini2-codex-live-agent-relay-019f4c2a", "body": "Can you check this branch?" }
+```
+
+Direct messages go to one exact session.
+
+```json
+{ "to": "tag:backend", "body": "Who owns the migration failure?" }
+```
+
+Tags fan out to every matching agent.
+
+```json
+{ "to": "cap:review", "claimable": true, "body": "Review PR #42" }
+```
+
+Claimable capability-routed messages act like a tiny work queue: many agents may
+see the work, but one agent claims it before acting.
+
+```json
+{
+  "target": "cap:ops",
+  "channel": "alerts",
+  "dedupeKey": "prod-api:5xx-rate",
+  "title": "prod-api 5xx rate high"
+}
+```
+
+Integration events create durable tasks. The dedupe key prevents alert storms
+from spamming agents with duplicate work.
+
+### Message And Task Lifecycle
+
+Messages and tasks are persisted in SQLite, so server restarts do not erase the
+inbox. Agents reconnect, heartbeat, and resume polling from the latest known
+message cursor.
+
+| Concept | What it means |
+|---------|---------------|
+| Claimable task | A message or integration task that exactly one agent should own. Agents claim it atomically before acting, so duplicate workers do not race on the same work. |
+| Read state | Read markers are stored per agent. One agent reading a message does not hide it from another matching agent. |
+| Threading | Replies set `replyTo`; the relay keeps the thread chain so the dashboard/API can show the conversation instead of isolated messages. |
+| Restart | The server reloads agents, messages, tasks, events, callbacks, and read markers from SQLite. Connected clients reconnect through polling/SSE/sidecars. |
+| Offline agents | Agents that stop heartbeating become `offline` after `STALE_TTL_MS`. Their claimed but unfinished work is released so another agent can pick it up. |
+| Pruning | Old messages are removed after `RETENTION_DAYS`. Long-offline agents are removed after `OFFLINE_PRUNE_MS`. Built-in/system agents are kept. |
+
+For task-like work, prefer `claimable: true` or integration tasks over plain
+broadcasts. For long-running work, update task status/progress so humans and
+tools can see whether it is claimed, blocked, done, failed, or canceled.
+
 ## Quick Start
 
 ### 1. Start the relay server
@@ -104,6 +224,9 @@ time, it starts a new thread by default to avoid surprising cwd-based attachment
 to an unrelated loaded session. Use `codex-relay --thread-mode auto` or
 `AGENT_RELAY_CODEX_FALLBACK_THREAD_MODE=auto` when you deliberately want the
 fallback sidecar to attach to the newest loaded thread for the current cwd.
+The lower-level sidecar also defaults to `CODEX_THREAD_MODE=start`; `auto` is an
+explicit opt-in because it may deliver relay messages into an already-open Codex
+session for the same directory.
 
 ### Codex approval mode
 
@@ -223,26 +346,6 @@ Example incoming relay message:
 | Label | `"label:test writer"` | All agents with that human-set label |
 | Broadcast | `"broadcast"` | Everyone |
 
-## Mental Model
-
-Agent Relay is a small trusted-network message bus:
-
-- **Server**: one Bun process with SQLite state and an HTTP API.
-- **Agent registration**: each Claude/Codex session registers an agent card with
-  id, labels, tags, capabilities, status, and readiness.
-- **Delivery**: Claude receives monitor notifications; Codex receives live turns
-  through the app-server sidecar.
-- **Routing**: direct ids target one session; tags/capabilities/labels fan out;
-  claimable messages are tasks where one matching agent claims before acting.
-- **Threads**: replies set `replyTo`; the server keeps a thread id so the
-  dashboard/API can show the conversation chain.
-- **Read state**: read markers are per agent. Deleting a message removes it from
-  history, so prefer retention settings over manual deletion for cleanup.
-- **Tasks**: integrations create durable work items. New open tasks also create
-  claimable system messages so one agent can pick up the work.
-- **Callbacks**: integrations can receive task lifecycle webhooks for closed-loop
-  automation.
-
 ## Integrations And Tasks
 
 Agent Relay can act as a secure ingress layer for scripts, monitoring systems,

package/codex/README.md

@@ -12,9 +12,9 @@ This sidecar connects to a Codex app-server session and to Agent Relay, then del
 
 ## Current behavior
 
-- attaches to a loaded thread for the current `cwd` when one exists
-- otherwise resumes the newest thread for the current `cwd`
-- otherwise creates a new thread
+- starts a new thread by default
+- resumes the actual launched thread when the SessionStart hook provides a thread id
+- only attaches to loaded/latest same-cwd threads when `CODEX_THREAD_MODE=auto`
 - registers a relay agent with `client: codex-live`
 - marks the relay agent `ready=true` once app-server + thread are attached
 - polls relay inbox and delivers messages into the live thread
@@ -131,6 +131,6 @@ startup in time.
 
 Current sidecar behavior is stable for live delivery. Remaining gaps are advanced policies such as batching by sender, message prioritization queues, and more nuanced retry/backoff behavior.
 
-- `CODEX_THREAD_MODE=auto` will attach to an already loaded thread for the same `cwd`. That is what you want for real live control, but it also means the sidecar can attach to your current interactive Codex session if one is already open.
-- For isolated testing, set `CODEX_THREAD_MODE=start` so the sidecar always creates its own thread.
+- `CODEX_THREAD_MODE=start` is the safe default: the sidecar creates its own thread unless the hook supplied an explicit thread id.
+- `CODEX_THREAD_MODE=auto` will attach to an already loaded thread for the same `cwd`. That can be useful for advanced live control, but it also means relay messages can enter your current interactive Codex session if one is already open.
 - A brand-new thread is not materialized for `includeTurns` reads until the first turn starts. That is an app-server behavior, not a relay bug.

package/codex/live-sidecar.test.ts

@@ -0,0 +1,20 @@
+import { describe, expect, it } from "bun:test";
+import { loadConfig, parseThreadMode } from "./live-sidecar";
+
+describe("codex live sidecar config", () => {
+  it("defaults to starting an isolated thread", () => {
+    const config = loadConfig({
+      CODEX_LIVE_CWD: "/tmp/agent-relay-test",
+    });
+
+    expect(config.threadMode).toBe("start");
+  });
+
+  it("only accepts known thread attachment modes", () => {
+    expect(parseThreadMode("auto")).toBe("auto");
+    expect(parseThreadMode("resume")).toBe("resume");
+    expect(parseThreadMode("start")).toBe("start");
+    expect(parseThreadMode("latest")).toBe("start");
+    expect(parseThreadMode(undefined)).toBe("start");
+  });
+});

package/codex/live-sidecar.ts

@@ -572,38 +572,43 @@ function describeError(error: unknown): string {
   return error instanceof Error ? error.message : String(error);
 }
 
-function envNumber(name: string, fallback: number): number {
-  const raw = process.env[name];
+function envNumber(env: NodeJS.ProcessEnv, name: string, fallback: number): number {
+  const raw = env[name];
   if (!raw) return fallback;
   const parsed = Number(raw);
   return Number.isFinite(parsed) && parsed > 0 ? parsed : fallback;
 }
 
-function loadConfig(): Config {
-  const cwd = process.env.CODEX_LIVE_CWD || process.cwd();
-  const capabilities = (process.env.AGENT_RELAY_CAPS || "chat")
+export function parseThreadMode(raw: string | undefined): Config["threadMode"] {
+  if (raw === "auto" || raw === "resume" || raw === "start") return raw;
+  return "start";
+}
+
+export function loadConfig(env: NodeJS.ProcessEnv = process.env): Config {
+  const cwd = env.CODEX_LIVE_CWD || process.cwd();
+  const capabilities = (env.AGENT_RELAY_CAPS || "chat")
     .split(",")
     .map((value) => value.trim())
     .filter(Boolean);
 
   return {
-    relayUrl: process.env.AGENT_RELAY_URL || "http://127.0.0.1:4850",
-    appServerUrl: process.env.CODEX_APP_SERVER_URL || "ws://127.0.0.1:4501",
+    relayUrl: env.AGENT_RELAY_URL || "http://127.0.0.1:4850",
+    appServerUrl: env.CODEX_APP_SERVER_URL || "ws://127.0.0.1:4501",
     cwd,
-    rig: process.env.CODEX_LIVE_RIG || "codex-live",
+    rig: env.CODEX_LIVE_RIG || "codex-live",
     capabilities,
-    tags: ["codex", process.env.CODEX_LIVE_RIG || "codex-live", cwd.split("/").filter(Boolean).at(-1) || "unknown"],
-    statePath: process.env.CODEX_LIVE_STATE_PATH || resolve(cwd, "codex/runtime/live-state.json"),
-    pollIntervalMs: envNumber("CODEX_LIVE_POLL_INTERVAL_MS", 2000),
-    heartbeatIntervalMs: envNumber("CODEX_LIVE_HEARTBEAT_INTERVAL_MS", 30000),
-    coalesceWindowMs: envNumber("CODEX_LIVE_COALESCE_WINDOW_MS", 600),
-    reconnectInitialDelayMs: envNumber("CODEX_LIVE_RECONNECT_INITIAL_MS", 1000),
-    reconnectMaxDelayMs: envNumber("CODEX_LIVE_RECONNECT_MAX_MS", 10000),
-    threadMode: (process.env.CODEX_THREAD_MODE as Config["threadMode"]) || "auto",
-    threadId: process.env.CODEX_THREAD_ID || undefined,
-    model: process.env.CODEX_MODEL || undefined,
-    approvalPolicy: process.env.CODEX_LIVE_APPROVAL_POLICY || undefined,
-    sandbox: process.env.CODEX_LIVE_SANDBOX || undefined,
+    tags: ["codex", env.CODEX_LIVE_RIG || "codex-live", cwd.split("/").filter(Boolean).at(-1) || "unknown"],
+    statePath: env.CODEX_LIVE_STATE_PATH || resolve(cwd, "codex/runtime/live-state.json"),
+    pollIntervalMs: envNumber(env, "CODEX_LIVE_POLL_INTERVAL_MS", 2000),
+    heartbeatIntervalMs: envNumber(env, "CODEX_LIVE_HEARTBEAT_INTERVAL_MS", 30000),
+    coalesceWindowMs: envNumber(env, "CODEX_LIVE_COALESCE_WINDOW_MS", 600),
+    reconnectInitialDelayMs: envNumber(env, "CODEX_LIVE_RECONNECT_INITIAL_MS", 1000),
+    reconnectMaxDelayMs: envNumber(env, "CODEX_LIVE_RECONNECT_MAX_MS", 10000),
+    threadMode: parseThreadMode(env.CODEX_THREAD_MODE),
+    threadId: env.CODEX_THREAD_ID || undefined,
+    model: env.CODEX_MODEL || undefined,
+    approvalPolicy: env.CODEX_LIVE_APPROVAL_POLICY || undefined,
+    sandbox: env.CODEX_LIVE_SANDBOX || undefined,
   };
 }
 
@@ -613,7 +618,9 @@ async function main(): Promise<void> {
   await sidecar.run();
 }
 
-main().catch((error) => {
-  console.error(error instanceof Error ? error.stack || error.message : String(error));
-  process.exit(1);
-});
+if (import.meta.main) {
+  main().catch((error) => {
+    console.error(error instanceof Error ? error.stack || error.message : String(error));
+    process.exit(1);
+  });
+}

package/codex/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-relay",
-  "version": "0.4.9",
+  "version": "0.4.11",
   "description": "Agent Relay integration for Codex sessions",
   "author": {
     "name": "Edin Mujkanovic"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-relay-server",
-  "version": "0.4.9",
+  "version": "0.4.11",
   "description": "Lightweight HTTP message relay for inter-agent communication across machines",
   "module": "src/index.ts",
   "type": "module",