PicoClaw
PicoClaw’s custom shell allowlist still cannot run its command
A PicoClaw report says commands accepted by custom allow patterns are later rejected by a second hardcoded shell-prefix gate. Another report shows identical tool failures can consume every iteration without a user answer, while Matrix can stop syncing permanently after one transient network failure.
sipeed/picoclaw PR #3313 is the inspected primary source: “Fix: agent not able to execute shell command added to customAllowPatterns.” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- sipeed/picoclaw PR #3313 was created 2026-08-03T00:48:18Z and was open at inspection; its title is “Fix: agent not able to execute shell command added to customAllowPatterns.” - sipeed/picoclaw issue #3311 was created 2026-08-02T18:13:19Z and was open at inspection; its title is “[BUG] Repeated identical tool failure loops silently to max_tool_iterations — user never gets an answer.” - sipeed/picoclaw PR #3312 was created 2026-08-02T18:13:57Z and was open at inspection; its title is “fix(agent): stop turn early on repeated identical tool failure.” - The repository reported 29799 stars, 59 open issues, default branch main, and last push 2026-07-30T18:32:36Z. - The latest tagged-release baseline checked was nightly published 2026-07-02T01:26:53Z.
What changed
sipeed/picoclaw PR #3313 reports: Description Bug: My agent was not able to execute 'git push' despite adding it to the exec allow list. According to the tests it should have worked. Fixed customAllowPatterns not working: default deny patterns always took precedence in guardCommand, so a command like git push could never be permitted via a custom allow pattern. Separated user-specified CustomDenyPatterns from the built-in defaults so security-critical custom deny rules (e.g. jq env-access checks) still always apply, while built-in deny patterns can be exempted by a matching custom allow pattern. Also fixed TestShellTool_CustomAllowPatterns, which previously passed vacuously: it never set an internal channel context, so the channel-restriction check blocked the command before the guard ran. The test now
sipeed/picoclaw issue #3311 reports: Quick Summary A turn can spin silently for many minutes (up to max_tool_iterations) when a tool fails with the **same error on every call**, and the user never receives an answer. Observed in production over Telegram: a message asking the agent to run a git command never got a reply because git failed with could not read Username for 'https://github.com' and the loop retried it ~40 times before the user gave up and restarted the service. Environment & Tools **PicoClaw Version:** v0.3.1 (git: 2cf030d) **Go Version:** 1.25.11 (build machine), 1.26.5 (repro) **AI Model & Provider:** deepseek-v4-flash via DeepSeek **Operating System:** Linux Mint 22 (Apple T2 MacBook) **Channels:** Telegram Steps to Reproduce 1. Send a
sipeed/picoclaw PR #3312 reports: Description Fix the "stuck / never answers" behavior seen when a tool fails with the **same error on every call** (e.g. git without credentials, or any command blocked by the shell safety guard). Previously the agent loop kept re-calling the LLM and re-executing the identical failing tool until max_tool_iterations — with **zero user feedback** in between — so messages over channels like Telegram appeared to be silently ignored. This PR adds a **circuit breaker**: consecutive identical (tool, error) failures are tracked in turnState.recordToolExecution, and when the same tool+error repeats repeatedFailureThreshold (3) times, the turn stops early with a clear, user-visible message explaining the repeated failure. Type of Change [x] Bug fix (non-breaking
Why it matters
A policy decision must remain authoritative through execution, and failure loops must make forward progress visible. Duplicated allow logic, silent retry exhaustion and a dead sync goroutine are three ways the control plane can say “allowed” or “running” while the user sees nothing. The operational test is whether persisted state, execution authority and visible user outcome describe the same event. Broad retries, hidden suppression or permission expansion can hide the symptom while making the boundary less trustworthy.
Current
The primary record was open when captured on 2026-08-03. The release baseline was nightly published 2026-07-02T01:26:53Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts HTML row were checked. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/sipeed/picoclaw/pull/3313. Supporting records are https://github.com/sipeed/picoclaw/issues/3311 and https://github.com/sipeed/picoclaw/pull/3312. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly 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. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Collapse shell authorization into one decision path, stop repeated identical failures early with a final explanation, and supervise Matrix sync with bounded reconnect and status evidence. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.
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.