caproom 0.1.0 → 0.2.0

package/README.md

@@ -1,15 +1,13 @@
 # caproom
 
-Memory-cap any command — AI coding agents, builds, background jobs — on macOS/Linux.
+[![npm](https://img.shields.io/npm/v/caproom.svg)](https://www.npmjs.com/package/caproom)
+[![license](https://img.shields.io/npm/l/caproom.svg)](LICENSE)
 
-## Why
-
-macOS has no working per-process memory limit in userspace. Verified empirically:
+Prevent RAM OOM for long-running terminal coding agents, builds, and background jobs — memory caps plus idle-process parking, for macOS/Linux.
 
-- `setrlimit(RLIMIT_AS, ...)`, `RLIMIT_DATA`, `RLIMIT_RSS` all return `EINVAL` on modern macOS — the kernel rejects them outright, `ulimit -v` included.
-- launchd's own `HardResourceLimits.ResidentSetSize` is a no-op — a job capped at 100MB was observed running past 590MB, still `state = active`.
+## Why
 
-So a runaway process — a leaking build tool, an AI agent that gets stuck in a loop, a stray `find /` — has nothing standing between it and system OOM on macOS. `caproom` fills that gap with the two mechanisms that actually work.
+macOS has no reliable way to cap a process's memory from userspace. A runaway process — a leaking build tool, an AI agent stuck in a loop, a stray `find /` — has nothing standing between it and system OOM. `caproom` fills that gap with mechanisms that actually enforce a limit.
 
 ## What it does
 
@@ -22,11 +20,9 @@ Two backends, auto-selected:
 1. **Docker cgroup** (`--memory`) — used when Docker is installed and running. Hard cap, real kernel enforcement, zero race window.
 2. **Polling watchdog** (`ps` RSS + `SIGKILL`) — fallback when Docker isn't available. No dependencies, works anywhere `ps` exists. Has a small race window bounded by `--interval` (default 200ms) — a process can spike briefly past the cap between polls before being killed.
 
-Both are honest about their mechanism: neither claims kernel-enforced rlimit, because that doesn't exist on macOS for arbitrary processes.
-
 ## Install
 
-```
+```bash
 npm install -g caproom
 ```
 
@@ -48,9 +44,38 @@ caproom --limit 1024 --force-watchdog -- ./some-script.sh
 caproom --limit 4096 --image python:3.12-slim -- python train.py
 ```
 
-Env var overrides: `CAPROOM_LIMIT_MB`, `CAPROOM_IMAGE`, `CAPROOM_INTERVAL`.
+### Flags
+
+| Flag | Default | Meaning |
+|---|---|---|
+| `--limit <mb>` | `4096` | memory cap in MB |
+| `--image <name>` | `node:22-slim` | docker image used by the docker backend |
+| `--interval <sec>` | `0.2` | watchdog poll interval |
+| `--grace <sec>` | `5` | seconds to wait after `SIGTERM` before `SIGKILL`, watchdog backend only — gives the process a chance to flush/save state before a hard kill |
+| `--force-watchdog` | off | use the polling watchdog even if Docker is available |
+
+Env var overrides: `CAPROOM_LIMIT_MB`, `CAPROOM_IMAGE`, `CAPROOM_INTERVAL`, `CAPROOM_GRACE`.
+
+On cap breach, the watchdog backend sends `SIGTERM` first and waits `--grace` seconds before `SIGKILL`. If the process exits cleanly during the grace window, `caproom` propagates its real exit code; only a hard `SIGKILL` (process ignored `SIGTERM`, or grace ran out) reports `137` (same convention as Docker's own OOM-kill exit code, which the docker backend always uses on breach since Docker itself sends the kill).
+
+## park / wake — reclaim idle memory without killing
+
+Long-running agent sessions accumulate subprocesses that go idle but stay resident — old file watchers, finished tool-call children, stale servers. Killing them loses state; leaving them wastes RAM. `caproom park` freezes instead:
+
+```bash
+caproom park <pid>     # SIGSTOP — process stays alive, keeps its PID and state,
+                        # just isn't scheduled. Its memory becomes eligible for
+                        # the kernel's own compressor once real system memory
+                        # pressure shows up.
+caproom wake <pid>      # SIGCONT — resumes instantly, same state, no restart.
+caproom status <pid>    # pid, state (T = parked, S = running), RSS, elapsed
+```
+
+Verified empirically on macOS: a parked process's RSS dropped ~90% (345MB → 37MB) once real memory pressure hit, and resumed correctly and stayed responsive after `SIGCONT`. No reclaim happens while the system is idle/unpressured — this rides the kernel's own compressor, it doesn't force anything.
+
+No daemon, no tracking file, no dependency — just `SIGSTOP`/`SIGCONT` wrapped in a CLI. Any script or agent can call `caproom park <pid>` / `caproom wake <pid>` directly.
 
-On cap breach, `caproom` kills the process and exits `137` (same convention as Docker's own OOM-kill exit code).
+**Caveat**: a parked process does zero work while stopped — no CPU, no I/O, no timers firing. Only park something actually idle (a background watcher, a finished subprocess kept around for reuse) — never park the process an agent is actively waiting on a response from, or you'll hang the agent, not save it memory.
 
 ## Limitations
 
@@ -58,6 +83,10 @@ On cap breach, `caproom` kills the process and exits `137` (same convention as D
 - Watchdog backend has a real (if small) race window; for a hard guarantee, use the Docker backend.
 - Neither backend can cap a process that immediately forks and hides children under a different watched PID tree in unusual ways — the watchdog only tracks the direct child.
 
+## Contributing
+
+Issues and PRs welcome at [github.com/intelogroup/caproom](https://github.com/intelogroup/caproom).
+
 ## License
 
 MIT

package/bin/caproom

@@ -12,26 +12,72 @@ set -euo pipefail
 usage() {
   cat >&2 << 'EOF'
 usage: caproom [--limit <mb>] [--image <docker-image>] [--interval <sec>] -- <command> [args...]
+       caproom park <pid>
+       caproom wake <pid>
+       caproom status <pid>
 
   --limit <mb>     memory cap in MB (default: 4096)
   --image <name>   docker image to run the command in, when using the docker
                     backend (default: node:22-slim)
   --interval <sec> watchdog poll interval in seconds, fallback backend only
                     (default: 0.2)
+  --grace <sec>    seconds to wait after SIGTERM before SIGKILL, watchdog
+                    backend only (default: 5) — gives the process a chance
+                    to flush/save state before a hard kill
   --force-watchdog force the polling watchdog even if Docker is available
 
-env vars (override flags): CAPROOM_LIMIT_MB, CAPROOM_IMAGE, CAPROOM_INTERVAL
+park / wake — freeze an idle process so the kernel can reclaim/compress its
+memory without killing it. For a long-running agent sitting on stale
+subprocesses: `caproom park <pid>` (SIGSTOP) instead of killing it. It stays
+alive, keeps its PID, keeps its state — just isn't scheduled and its memory
+becomes eligible for compression under system memory pressure. `caproom wake
+<pid>` (SIGCONT) brings it back instantly, same state, no restart needed.
+Any agent can call these directly — they're just SIGSTOP/SIGCONT, no daemon,
+no tracking file required.
+
+env vars (override flags): CAPROOM_LIMIT_MB, CAPROOM_IMAGE, CAPROOM_INTERVAL, CAPROOM_GRACE
 
 examples:
   caproom --limit 2048 -- npm run build
   caproom --limit 512 -- claude --dangerously-skip-permissions -p "task"
+  caproom park 12345
+  caproom wake 12345
 EOF
   exit 1
 }
 
+cmd_park() {
+  local pid="${1:-}"
+  [[ -z "$pid" ]] && { echo "usage: caproom park <pid>" >&2; exit 1; }
+  kill -0 "$pid" 2>/dev/null || { echo "caproom: no such pid $pid" >&2; exit 1; }
+  kill -STOP "$pid"
+  echo "caproom: pid $pid parked (SIGSTOP) — memory now eligible for kernel reclaim under pressure. wake with: caproom wake $pid" >&2
+}
+
+cmd_wake() {
+  local pid="${1:-}"
+  [[ -z "$pid" ]] && { echo "usage: caproom wake <pid>" >&2; exit 1; }
+  kill -0 "$pid" 2>/dev/null || { echo "caproom: no such pid $pid" >&2; exit 1; }
+  kill -CONT "$pid"
+  echo "caproom: pid $pid woken (SIGCONT)" >&2
+}
+
+cmd_status() {
+  local pid="${1:-}"
+  [[ -z "$pid" ]] && { echo "usage: caproom status <pid>" >&2; exit 1; }
+  ps -o pid,stat,rss,etime,command -p "$pid" 2>/dev/null || { echo "caproom: no such pid $pid" >&2; exit 1; }
+}
+
+case "${1:-}" in
+  park) shift; cmd_park "$@"; exit 0 ;;
+  wake) shift; cmd_wake "$@"; exit 0 ;;
+  status) shift; cmd_status "$@"; exit 0 ;;
+esac
+
 LIMIT_MB="${CAPROOM_LIMIT_MB:-4096}"
 IMAGE="${CAPROOM_IMAGE:-node:22-slim}"
 INTERVAL="${CAPROOM_INTERVAL:-0.2}"
+GRACE="${CAPROOM_GRACE:-5}"
 FORCE_WATCHDOG=0
 
 while [[ $# -gt 0 ]]; do
@@ -39,6 +85,7 @@ while [[ $# -gt 0 ]]; do
     --limit) LIMIT_MB="$2"; shift 2 ;;
     --image) IMAGE="$2"; shift 2 ;;
     --interval) INTERVAL="$2"; shift 2 ;;
+    --grace) GRACE="$2"; shift 2 ;;
     --force-watchdog) FORCE_WATCHDOG=1; shift ;;
     --) shift; break ;;
     -h|--help) usage ;;
@@ -69,9 +116,21 @@ run_watchdog() {
     local rss_kb
     rss_kb=$(ps -o rss= -p "$pid" 2>/dev/null | tr -d ' ')
     if [[ -n "$rss_kb" && "$rss_kb" -gt "$limit_kb" ]]; then
-      echo "caproom: pid $pid RSS ${rss_kb}KB exceeded ${limit_kb}KB cap — killing" >&2
-      kill -9 "$pid" 2>/dev/null || true
-      exit 137
+      echo "caproom: pid $pid RSS ${rss_kb}KB exceeded ${limit_kb}KB cap — sending SIGTERM (grace ${GRACE}s)" >&2
+      kill -TERM "$pid" 2>/dev/null || true
+      local waited=0
+      while kill -0 "$pid" 2>/dev/null && [[ "$waited" -lt "$GRACE" ]]; do
+        sleep 1
+        waited=$(( waited + 1 ))
+      done
+      if kill -0 "$pid" 2>/dev/null; then
+        echo "caproom: pid $pid still alive after ${GRACE}s grace — SIGKILL" >&2
+        kill -9 "$pid" 2>/dev/null || true
+        exit 137
+      fi
+      wait "$pid" 2>/dev/null || exit_code=$?
+      echo "caproom: pid $pid exited cleanly (code $exit_code) during grace period" >&2
+      exit "$exit_code"
     fi
     sleep "$INTERVAL"
   done

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "caproom",
-  "version": "0.1.0",
-  "description": "Memory-cap any command (AI coding agents, builds, background jobs) on macOS/Linux — real enforcement via Docker cgroups or a polling watchdog, since macOS has no working per-process memory rlimit.",
+  "version": "0.2.0",
+  "description": "Memory-cap any command (AI coding agents, builds, background jobs) on macOS/Linux — real enforcement via Docker cgroups or a polling watchdog, plus park/wake to reclaim idle process memory without killing.",
   "bin": {
     "caproom": "bin/caproom"
   },
@@ -12,11 +12,12 @@
     "memory",
     "oom",
     "cgroup",
-    "rlimit",
     "macos",
     "watchdog",
     "ai-agent",
-    "process-limit"
+    "process-limit",
+    "park",
+    "idle-memory"
   ],
   "os": [
     "darwin",