@scrylog/cli 0.5.0 → 0.5.1

package/README.md

@@ -1,6 +1,8 @@
 # scrylog
 
-`scrylog` is a Bun-based terminal dashboard and daemon for monitoring AI coding sessions in `tmux`, herdr, and as standalone processes.
+**scrylog** monitors AI coding sessions from Claude Code, Codex, and OpenCode in one terminal dashboard: session states, required attention, provider usage limits, and optional Telegram notifications, with REST/SSE and MCP access for integrations.
+
+Sessions are discovered as standalone processes or through `tmux` and herdr. `tmux` is optional — every collector degrades gracefully when its source is absent.
 
 It ships four commands:
 
@@ -13,11 +15,14 @@ It ships four commands:
 
 ## Features
 
+- Claude Code session monitoring via transcript collection
+- Codex session monitoring via transcript collection and hook-based state tracking
+- OpenCode integration in `hooks` or `sse` mode, with SQLite-based session enrichment
+- Session states (`working`, `idle`, `waiting-input`, `error`) and permission/question attention visibility
+- Provider usage and subscription limits for Claude, Codex, and OpenCode Go, on the dashboard and `GET /api/usage`
+- Telegram notifications for session events and usage alerts, including `user-idle` delivery gating
 - `tmux` monitoring for OpenCode, Codex, Copilot, and shell panes
 - herdr default-session monitoring through its structured agent and pane API
-- OpenCode integration in `hooks` or `sse` mode
-- Claude transcript collection
-- Codex transcript collection and hook-based state tracking
 - Local daemon with Unix socket IPC on macOS and Linux, TCP fallback on Windows
 - Optional TCP REST API exposure (enabled by default on Windows)
 - Optional MCP HTTP exposure with bearer token support
@@ -27,6 +32,8 @@ It ships four commands:
 
 ## Requirements
 
+Only [Bun](https://bun.sh) is required. The rest are optional per data source, and their absence is handled automatically:
+
 - [Bun](https://bun.sh) `>= 1.3.0`
 - `tmux` if you want `tmux` monitoring
 - [herdr](https://herdr.dev) if you want herdr monitoring; absence is handled automatically
@@ -106,7 +113,23 @@ Known limitations (they are the deliberate trade-off of ignoring cursor movement
 - Reading documentation, watching a presentation, or working with no keyboard presses or mouse clicks counts as idle under this source: expect a notification while you are still at the machine if you are not touching input.
 - Media keys and special hardware buttons may not be reported by the OS as key presses; the idle clock stays valid but such events do not reset it.
 - On Windows and Linux the activity clock starts when the daemon starts (observation begins with the notification service, before the first notification); input before that moment is unrecoverable, so an idle-before-start machine behaves as "unknown" and follows the channel's `onUnknown` policy. Backends keep running across the whole daemon lifetime once started, and a bounded heartbeat on Linux keeps the input queues healthy.
-- `scrylog doctor` shows the effective source, the resolved backend, and any availability reason when `keyboard-clicks` is selected.
+- `scrylog doctor` shows the configured source, the resolved backend, and any availability reason when `keyboard-clicks` is selected. On WSL, `powershell-hook (windows host, ready)` means a PowerShell candidate is reachable through interop; it does not verify that the running daemon's input hooks are installed or receiving events.
+
+### Observed WSL behavior with an automatic mouse mover
+
+In a user-reported manual test on WSL, the daemon was restarted after changing the activity source. The following notification behavior was observed:
+
+| Activity source   | Input during the test                                   | Observed result            |
+| ----------------- | ------------------------------------------------------- | -------------------------- |
+| `system`          | Only movement from the automatic mouse-mover device     | Notification was not sent. |
+| `keyboard-clicks` | Only movement from the automatic mouse-mover device     | Notification was sent.     |
+| `keyboard-clicks` | Manual mouse movement, without clicks or keyboard input | Notification was not sent. |
+
+This was useful in the tested environment: automatic movement allowed notifications during the user's absence, while manual mouse use blocked them.
+
+The distinction between manual and automatic movement is an observation, not an explicit capability of the implemented filter. The filter ignores mouse-movement and wheel events and observes key presses and mouse button events. The cause of the observed difference has not been determined, and this result has not been validated with other devices or platforms. Windows version, WSL version, device model, and input-event traces were not captured for this report.
+
+### Verifying activity detection
 
 To confirm the source is actually working, set `daemon.logLevel: "debug"` (with `daemon.logFileEnabled: true`) and watch the daemon log (`scrylog logs`) for these events — none of them ever log key content, coordinates, or event history:
 

package/package.json

@@ -1,19 +1,24 @@
 {
   "name": "@scrylog/cli",
-  "version": "0.5.0",
-  "description": "Terminal dashboard for monitoring tmux sessions running AI coding agents",
+  "version": "0.5.1",
+  "description": "Terminal dashboard and daemon for monitoring AI coding agents across standalone, tmux, and herdr sessions, with usage tracking and notifications",
   "keywords": [
+    "ai-agents",
     "bun",
     "claude",
+    "claude-code",
     "cli",
     "codex",
     "dashboard",
+    "herdr",
     "mcp",
+    "notifications",
     "opencode",
     "ssh",
     "terminal",
     "tmux",
-    "tui"
+    "tui",
+    "usage-monitoring"
   ],
   "homepage": "https://github.com/scrylog/scrylog#readme",
   "bugs": {