Paperclip
Paperclip traces four-hour agent stalls to execution plumbing
Paperclip reports pi_local shell calls that can burn four hours without a timeout and spawned agents that cannot see common user-installed toolchains. A bridge patch separately keeps remote sandbox API relays from dying or wedging at 64 orphaned requests.
paperclipai/paperclip PR #12060 is the inspected primary source: “fix: harden the sandbox bridge gateway against crashes and queue wedge.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- paperclipai/paperclip PR #12060 was created 2026-08-24T00:06:18Z and was open at inspection; its title is “fix: harden the sandbox bridge gateway against crashes and queue wedge.” - paperclipai/paperclip issue #12058 was created 2026-08-24T00:02:48Z and was open at inspection; its title is “pi_local adapter: bash tool has no default timeout — agents can hang for 4+ hours before silence detector trips.” - paperclipai/paperclip issue #12057 was created 2026-08-24T00:02:37Z and was open at inspection; its title is “Spawned agent processes inherit a stripped PATH — cargo, rustc, bun, pnpm, brew all missing.” - The repository reported 79242 stars, 5319 open issues, default branch master, and last push 2026-08-24T00:37:37Z. - The latest tagged-release baseline checked was v2026.817.0 published 2026-08-18T03:17:29Z.
What changed
paperclipai/paperclip PR #12060 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Agents on remote sandbox targets reach the Paperclip API through the sandbox callback bridge: a loopback HTTP gateway inside the sandbox queues request files for a host-side worker - The gateway process has no supervisor: nothing inside the sandbox respawns it, so a crash leaves a dead loopback port for the rest of the run - The gateway also never cleaned up request files whose responses never arrived, so a stalled host wedged the queue at its depth cap and every later request got an immediate 503 - #12052 made the host-side worker survive transient faults; this pull request hardens the other half of the relay - The benefit is that a gateway fault degrades one request instead of severing the agent from the control plane until run end Linked Issues or Issue Description Refs #12052 (host-side worker half of the same relay). Refs #9904 and #8977 (adjacent bridge behavior). No public issue exists for this defect. The description below follows the bug report template. What happened?** During a staging run, an agent's API calls to the bridge's loopback port began failing at the connection level (curl reported HTTP 000) partway through the run. A dead gateway process is the only mechanism
paperclipai/paperclip issue #12058 reports: Summary The pi adapter spawns the agent's bash tool with no default timeout. Commands like find /, cargo test, apt-get install, or any long-running operation can hang the agent process indefinitely. Paperclip considers the agent "running" (process alive) but produces no stdout, so the silence detector's 1h/4h thresholds never trip — the agent bills the full 4 hours as "running" without doing useful work. Environment paperclipai: **2026.722.0** pi: **v0.84.2 adapter: pi_local OS: Linux Reproduction 1. Assign any pi_local agent an issue. 2. Let the agent run for a few minutes. Once it has its bearings, it will likely run a discovery command. 3. Watch the run log. The agent typically runs commands like: 4. ls returns immediately (ls: cannot access...). find / walks the entire filesystem. No timeout fires. 5. Inspect Paperclip's run record: status=running, lastOutputAt is hours ago, silenceAgeMs keeps growing, but the process is alive. 6. The agent does no useful work until the silence threshold (4 h) trips, at which point Paperclip finally marks the run as failed. Concrete examples from real sessions **Run 3450a29e (GPU engineer, 2026-08-23T22:40:57)**: 4 LLM calls in the first 3 minutes, then last bash tool call was ls...; find / -name rustup; find / -name cargo — find / never returned, agent silent for 3+ hours before cancellation. **Run cb46a49e
paperclipai/paperclip issue #12057 reports: Summary Spawned agent processes inherit a stripped-down PATH that excludes the user-installed development tools (cargo, rustc, bun, pnpm, linuxbrew binaries, etc.). Agents cannot run the same commands the human user runs interactively, even on the same machine, in the same shell session. Environment paperclipai: **2026.722.0** adapter: pi_local (also affects claude_local, codex_local, etc. — any spawn-from-shell-process adapter) OS: Linux (Ubuntu 24.04) User shell: bash with ~/.bashrc that does. "$HOME/.cargo/env" (cargo, rustc on PATH) Paperclip server process: started via npm exec paperclipai run, inherits the npm-spawned env which lacks the bashrc-sourced paths Reproduction 1. Start Paperclip normally (paperclipai run). 2. As the human user on the same machine, in the same session: which cargo → /home/avconnected/.cargo/bin/cargo. Rust toolchains work. 3. Trigger a Paperclip heartbeat run on any issue assigned to a pi_local agent. 4. Inspect the spawned pi process environment: 5. The spawned pi process has **no ~/.cargo/bin**, no ~/.bun/bin, no ~/.local/pnpm, no /home/linuxbrew/.linuxbrew/bin, etc. 6. Ask the agent to do anything Rust / Node / pnpm / brew-related. Result: cargo: command not found (exit 127), or bun: command not found, etc. Concrete commands the human user can run that the spawned agent cannot: | Command | Human (interactive bash) | Spawned agent (via Paperclip) | |---|---|---| | cargo --version | cargo 1.98.0 | cargo: command not found | | rustc
Why it matters
The failure cluster shows that a live process is not evidence of useful work; execution needs bounded commands, a declared environment and a relay that recovers request by request. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-24. The tagged-release baseline was v2026.817.0 published 2026-08-18T03:17:29Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/paperclipai/paperclip/pull/12060. Supporting records are https://github.com/paperclipai/paperclip/issues/12058 and https://github.com/paperclipai/paperclip/issues/12057. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Set an auditable default tool timeout, make spawn PATH explicit, and treat bridge readiness, stale request cleanup and caller cancellation as one liveness contract. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.