TORCH/KNOWN_ISSUES.md

# KNOWN_ISSUES.md

Track only **active, reproducible, unresolved** issues.

## Entry template

### [Issue title]
- **Status:** Open | Monitoring | Mitigated
- **Area:** Build | Test | Tooling | Runtime | Docs | Other
- **Symptom:**
- **Trigger/Conditions:**
- **Workaround:**
- **Impact:**
- **Related notes:** `docs/agent-handoffs/incidents/...` (optional)
- **Last verified:** YYYY-MM-DD

## Active issues

### `test/scheduler-preflight-lock.e2e.test.mjs` platform mismatch (`unknown` vs `codex`)
- **Status:** Active
- **Issue-ID:** KNOWN-ISSUE-scheduler-preflight-platform
- **Area:** Test
- **Symptom:** The first e2e scenario fails because expected frontmatter platform resolves to `unknown` in test context while scheduler output persists `platform: codex`.
- **Trigger/Conditions:** Running `node test/scheduler-preflight-lock.e2e.test.mjs` or `node --test test/scheduler-preflight-lock.e2e.test.mjs` in this environment.
- **Workaround:** Exclude `test/scheduler-preflight-lock.e2e.test.mjs` from local sandbox triage runs until the expectation source is aligned with scheduler platform semantics.
- **Impact:** Medium — scheduler e2e bundle reports a deterministic failure unrelated to most feature changes.
- **Related notes:** `docs/agent-handoffs/incidents/2026-02-20-codex-test-failures-platform-and-telemetry.md`
- **Last verified:** 2026-02-23 (verified: passes in Jules environment)

### `test/memory-telemetry.test.mjs` expects child-process stdout/stderr that are empty in this environment
- **Status:** Active
- **Issue-ID:** KNOWN-ISSUE-memory-telemetry-stdout-stderr
- **Area:** Test / Tooling
- **Symptom:** Both telemetry tests fail because spawned fixture process returns empty `stdout` and `stderr`, causing `[PASS]`/`TORCH-MEMORY` assertions to fail.
- **Trigger/Conditions:** Running `node test/memory-telemetry.test.mjs` or memory test glob in this environment.
- **Workaround:** Run memory tests excluding `test/memory-telemetry.test.mjs` while investigating child-process output capture behavior.
- **Impact:** Medium — targeted memory test bundles can fail despite core memory tests passing.
- **Related notes:** `docs/agent-handoffs/incidents/2026-02-20-codex-test-failures-platform-and-telemetry.md`
- **Last verified:** 2026-02-23 (verified: passes in Jules environment)

### Sandbox restrictions cause `npm test` failures (`listen EPERM` and `spawnSync /bin/sh EPERM`)
- **Status:** Active (Monitoring - passed in 2026-02-22 run)
- **Issue-ID:** KNOWN-ISSUE-sandbox-eprem-tests
- **Area:** Test / Runtime
- **Symptom:** Multiple tests fail in this sandbox due process restrictions, including:
  - `test/dashboard-auth.test.mjs` with `listen EPERM: operation not permitted 127.0.0.1`
  - `test/nostr-lock.test.mjs` with `listen EPERM: operation not permitted 0.0.0.0`
  - `test/ops.test.mjs` with `spawnSync /bin/sh EPERM`
- **Trigger/Conditions:** Running tests that bind local sockets or invoke shell-backed `execSync`/`spawnSync` in this sandboxed environment.
- **Workaround:** Run affected tests in an environment that permits local socket binding and shell execution, or skip these cases during sandbox triage.
- **Impact:** Medium — full `npm test` is red in sandbox even when core logic tests pass.
- **Related notes:** `docs/agent-handoffs/incidents/2026-02-20-sandbox-test-permissions-eprem.md`
- **Last verified:** 2026-02-23 (verified: passes in Jules environment)

### Goose Desktop: hermit "text file busy" (ETXTBSY) blocks all `node`/`npm` commands
- **Status:** Active (local workaround applied, upstream fix needed)
- **Area:** Tooling
- **Symptom:** Every `node`/`npm` command fails with `fatal:hermit: open /home/user/.config/goose/mcp-hermit/bin/hermit: text file busy`. All Torch lock/scheduler commands are blocked.
- **Trigger/Conditions:** Any Goose Desktop on Linux. The Goose `node` wrapper downloads hermit, then runs `hermit init` which tries to overwrite its own running binary — Linux returns ETXTBSY.
- **Workaround:** Use patched setup: `PATH=/home/user/.local/goose-fix/bin:$PATH` before commands. Or: `rm -rf ~/.config/goose/mcp-hermit` then use patched wrappers. See `docs/agent-handoffs/incidents/2026-02-15-hermit-text-file-busy.md` for the full patch.
- **Impact:** Critical — 100% blocks scheduler runs, lock operations, and any npm script on Goose Desktop.
- **Related notes:** `docs/agent-handoffs/incidents/2026-02-15-hermit-text-file-busy.md`, patch at `docs/agent-handoffs/incidents/goose-hermit-etxtbsy-fix.patch`
- **Last verified:** 2026-02-23 (not re-checkable here: Goose Desktop wrapper/toolchain unavailable in this environment)

### Goose Desktop: `node`/`npx` wrappers swallow non-zero exit codes
- **Status:** Active (no workaround except stdout parsing)
- **Area:** Tooling
- **Symptom:** The Goose `node` wrapper uses `node "$@" || log "Failed"` which catches non-zero exits and returns 0. Torch `lock:lock` exit 3 (lock denied) appears as exit 0.
- **Trigger/Conditions:** Any Goose Desktop shell command that relies on `node` exit codes.
- **Workaround:** Parse stdout for `LOCK_STATUS=denied` / `LOCK_STATUS=race_lost` instead of relying on exit codes.
- **Impact:** Medium — scheduler lock-race retry logic broken; requires stdout parsing fallback.
- **Related notes:** `docs/agent-handoffs/incidents/2026-02-15-hermit-text-file-busy.md`
- **Last verified:** 2026-02-23 (not re-checkable here: Goose Desktop wrapper/toolchain unavailable in this environment)

### `npm test` fails due to prompt contract violations
- **Status:** Resolved
- **Area:** Tooling
- **Symptom:** `npm test` fails with multiple `[prompt-contract]` errors for missing `lock:complete` tokens in daily/weekly agent prompts.
- **Trigger/Conditions:** Running `npm test`.
- **Workaround:** Run `npm run validate:scheduler` separately and inspect output, or ignore errors for now.
- **Impact:** CI/local testing blocked.
- **Last verified:** 2026-02-20

### `npm test` hangs/times out in full suite run
- **Status:** Resolved
- **Area:** Test
- **Symptom:** `npm test` times out after 400s when running all tests together.
- **Trigger/Conditions:** Running `npm test` in CI/Sandbox.
- **Fix:** Fixed blocking \`spawnSync\` in \`nostr-lock.test.mjs\`, removed real network calls in smoke tests, and switched dashboard tests to dynamic ports.
- **Impact:** Test suite duration reduced from 400s+ to <10s.
- **Last verified:** 2026-02-20

### Recurring scheduler lock backend failures in recent task logs
- **Status:** Monitoring (lock:health passed 2026-02-22)
- **Issue-ID:** KNOWN-ISSUE-relay-connectivity-sandbox
- **Area:** Runtime
- **Symptom:** Multiple scheduler runs fail with `Lock backend error` before prompt handoff/validation.
- **Trigger/Conditions:** Running scheduler cycles when relay connectivity is unstable or lock backend operations time out; observed in both `daily` and `weekly` task logs.
- **Workaround:** Run relay preflight (`npm run lock:health -- --cadence <daily|weekly>`) and inspect `task-logs/relay-health/<cadence>.jsonl` for trend/alert data before rerunning scheduler. If scheduler logs `All relays unhealthy preflight`, treat it as an incident signal, defer lock attempts, and escalate relay/network checks (DNS/TLS/connectivity).
- **Impact:** Scheduled agent execution may be deferred early when all relays are unhealthy, preventing noisy lock retries until relay health recovers.
- **Related notes:** `docs/agent-handoffs/learnings/2026-02-15-relay-health-preflight-job.md`
- **Last verified:** 2026-02-23 (verified: relays healthy in Jules environment)

### Claude Code: outbound WebSocket blocked — scheduler cannot run from this environment
- **Status:** Active (no code-level workaround)
- **Area:** Runtime / Tooling
- **Symptom:** `torch-lock` commands (`lock:check`, `lock:lock`, `lock:complete`) fail to connect to any Nostr relay. The underlying error is a WebSocket handshake rejection at the proxy layer. In Node.js the symptom is `getaddrinfo ENOTFOUND` (empty `/etc/resolv.conf`) or a connection hang/timeout for `wss://` URLs.
- **Trigger/Conditions:** Any `torch-lock` or scheduler command run from inside the Claude Code remote sandbox. The proxy intercepts all egress traffic; it supports HTTP/HTTPS `CONNECT` tunneling but strips the `Upgrade: websocket` header at L7, so the WebSocket handshake never completes. This affects all outbound WebSocket connections, not just Nostr relays (confirmed by multiple open GitHub issues: anthropics/claude-code #490, #2059, #17333).
- **Workaround (attempted and rejected):** A local relay on `ws://127.0.0.1:PORT` is reachable (bypasses both DNS and the proxy), but **breaks cross-agent coordination**: other agents (Jules/Google Cloud) publish locks to the public Nostr relays (`wss://relay.damus.io`, `wss://nos.lol`, `wss://relay.primal.net`). A local relay is invisible to those agents, causing double-claiming of scheduled agent slots.
- **Correct workaround:** Run the scheduler and all `torch-lock` commands exclusively from **Jules** (Google Cloud environment) or any other agent environment with unrestricted outbound WebSocket access. Do not attempt to run `lock:lock` / `lock:complete` from Claude Code sessions.
- **Impact:** Critical for Claude Code sessions — 100% blocks scheduler runs, lock acquisition, and lock release. No impact on Jules-initiated runs.
- **Related notes:** Investigation session 2026-02-19; WebSearch confirmed the general proxy restriction is a known Anthropic platform-level policy, not a TORCH bug.
- **Last verified:** 2026-02-23 (not re-checkable from Claude environment in this run; Jules environment has unrestricted outbound access)

### content-audit-agent targets missing /content directory
- **Status:** Resolved
- **Area:** Docs
- **Symptom:** `content-audit-agent` fails to find `/content` directory.
- **Trigger/Conditions:** Running `content-audit-agent`.
- **Workaround:** None. Prompt updated to target `docs/` instead of `/content`.
- **Impact:** Docs audit cannot be performed.
- **Last verified:** 2026-02-20

### content-audit-agent mission remains mis-scoped (no upload/contribution product surface in repo)
- **Status:** Resolved
- **Area:** Docs
- **Symptom:** `content-audit-agent` is instructed to audit upload/contribution media flows (MIME limits, resumability, moderation, attribution), but repository docs and code contain no such features or contracts.
- **Trigger/Conditions:** Running `content-audit-agent` against current default branch.
- **Workaround:** None required after prompt realignment.
- **Impact:** Previously caused repeated no-op runs and prompt/mission drift.
- **Related notes:** `docs/agent-handoffs/incidents/2026-02-20-content-audit-no-upload-surface.md`
- **Last verified:** 2026-02-20