[seanwevans]

Nine independent issues found by auditing the codebase against SPEC.md and by exercising each component against a live PostgreSQL 16 instance. Each is one self-contained commit with its own regression test, so any of them can be reverted or cherry-picked alone.

Every test added here was confirmed to fail against the unpatched code and pass after the fix. Full suite: 102 passed, 1 skipped (was 76 passed, 1 skipped).

Findings

1. env_snapshot bypasses the executable allowlist (6c87561)

run_subprocess rejected only DATABASE_URL and PG_CONN, then merged the rest of the untrusted snapshot into the child environment. A snapshot carrying LD_PRELOAD makes the dynamic loader run attacker-supplied code inside an allowlisted binary:

run_subprocess("/usr/bin/printf hi", cwd, {"LD_PRELOAD": "/tmp/evil.so"})
-> (42, 'PWNED: arbitrary code ran inside an allowlisted binary\n')

No new executable is ever launched, so the allowlist check never sees the payload — defeating what the README documents as the required process isolation boundary. Now rejects LD_*, DYLD_*, BASH_FUNC_* by prefix plus the glibc path overrides with the same effect, case-insensitively. LDAP_URL and friends still pass through.

2. latest_output returns the two branches in opposite orders (27d0cdd)

The p_since_id = 0 backfill returned ORDER BY c.id DESC LIMIT 20; every later poll returned ORDER BY c.id ASC. Both callers render rows in arrival order, so both rendered a scrambled transcript: the htmx UI loaded history newest-at-top while hx-swap="beforeend" appended new commands at the bottom, and shell_cli tail without --since printed the backlog in reverse before switching to chronological. The DESC + LIMIT now lives in an inner query so "last N commands" is preserved while the result is oldest-first.

latest_output_html also sequenced fragments by row_number() OVER () with no ORDER BY, which is unspecified — it inherited whatever order the planner chose. Now ordered by command id.

3. Executor warns on every poll (2ea2663)

fetch_pending opened its transaction with an explicit BEGIN that psycopg2 had already issued implicitly, so PostgreSQL answered every poll with WARNING: there is already a transaction in progress — 86,400 log lines a day per worker at the default POLL_INTERVAL. Verified: 18 warnings before the fix, 0 across an 8-second polling run after.

4. Cleanup daemon dies on any transient database error (c70701b)

A failed connection logged and break, then fell off the end of main() returning None — so the process exited 0. A momentary PostgreSQL restart permanently stopped retention, and the zero status meant Restart=on-failure would not bring it back. Errors from cleanup_once were not caught at all. Now retries with backoff like monitor_agent already does; --once returns 1 on failure so cron and systemd notice.

5. Cleanup resets sessions outside SHELL_ROOT (aee3145)

cleanup_once reset stale environments to a literal /home/sandbox while the executor resolves the root from SHELL_ROOT. A deployment following the README's own worked example (SHELL_ROOT=/home/pg-shell-command) had sessions reset to a directory that usually does not exist, and the executor passes environments.cwd straight to the subprocess:

run_subprocess("/usr/bin/printf hi", "/home/sandbox", None)
-> FileNotFoundError: [Errno 2] No such file or directory: '/home/sandbox'

Every later command in a reset session failed. Default is unchanged, so existing deployments are unaffected.

6. One busy session starves every other session (2c3f728)

fetch_pending selected a single candidate and returned None when its per-session advisory lock was held, so sessions queued behind it never ran:

session A (submitted first): claim lock held by a peer worker
session B (submitted second): pending, ready to run

worker B poll 1: None
worker B poll 2: None
worker B poll 3: None

Reachable whenever a worker's lease expires while it is still alive and holding the lock — exactly the case the requeue at the top of fetch_pending exists to handle. SPEC.md §3 asks for per-user serialization "while still allowing different users to execute concurrently". Now fetches up to CLAIM_CANDIDATES rows and takes the first session whose lock is free. The NOT EXISTS predicate already admits at most one command per session, so candidates are distinct sessions and the serialization guarantee is unchanged.

7. monitor_state is never committed (ef846b0)

ensure_monitor_state_table created the table but left committing to save_monitor_state, which is skipped on every --since-hours/--since-days run and any run with nothing newly completed. conn.close() then rolled it back:

DROP TABLE monitor_state
python -m workers.monitor_agent --once --since-days 1
SELECT to_regclass('monitor_state') IS NOT NULL  ->  f

The agent re-ran CREATE TABLE every poll and, without init_schema.sql installed, could never keep a watermark — so collect_metrics re-aggregated the full history each time.

8. monitor_agent.__doc__ is None (5903fcb)

from __future__ import annotations sat above the module docstring, demoting it to a dead expression statement; help() and pydoc showed nothing. Also corrected main() -> None, which already returned exit codes.

9. install.sql warns on every run (5c766a2)

psql's \i takes the rest of the line as arguments, so a trailing comment produced seven warning: \i: extra argument ... ignored lines per install, burying real diagnostics.

Verification

• Full suite against PostgreSQL 16: 102 passed, 1 skipped (the skip is the pre-existing Playwright browser test).
• sql/install.sql applies cleanly to a virgin database and is idempotent on re-run, with zero psql warnings.
• Live end-to-end executor run: commands execute in submission order, cd updates the session environment, and the following command picks up the new cwd at claim time.

Note on PR granularity

You asked for one PR per issue. This session is pinned to a single designated branch, so all nine landed here as separate commits instead — each is self-contained with its own test and can be reverted independently. Happy to split them into separate PRs if you'd prefer.

🤖 Generated with Claude Code

https://claude.ai/code/session_017jvrX4SVJvSJKVsSHKCNEe

---

Generated by Claude Code