ZeroClaw
ZeroClaw finds temporary image paths surviving into memory
A ZeroClaw report says persisted image markers can retain temporary source paths and emit repeated warnings after the files disappear. A related patch pins image generation to a validated host, while queued-message recovery work adds explicit operator actions.
zeroclaw-labs/zeroclaw issue #10045 is the inspected primary source: “[Bug]: Persisted image markers can retain temporary source paths and repeatedly warn.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- zeroclaw-labs/zeroclaw issue #10045 was created 2026-08-16T18:51:38Z and was open at inspection; its title is “[Bug]: Persisted image markers can retain temporary source paths and repeatedly warn.” - zeroclaw-labs/zeroclaw PR #10046 was created 2026-08-16T20:00:59Z and was open at inspection; its title is “fix(tools): pin image_gen to the validated host and cover the redirect boundary.” - zeroclaw-labs/zeroclaw issue #10044 was created 2026-08-16T18:41:04Z and was open at inspection; its title is “[Feature]: Add recovery actions for queued ZeroCode messages.” - The repository reported 32599 stars, 726 open issues, default branch master, and last push 2026-08-17T00:25:37Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.
What changed
zeroclaw-labs/zeroclaw issue #10045 reports: Affected component runtime/daemon Severity S2 - degraded behavior Current behavior An image attachment can be copied into the agent workspace while its persisted [IMAGE:...] marker still references the original source path. This is normally harmless for stable user files, but temporary files created by terminal or clipboard integrations can disappear after the message is saved. When the session is resumed or continues through later turns, provider-message preparation scans the retained marker on every model request and tool-loop iteration. Each failed load emits the same warning and the model continues without the image: skipping multimodal image that could not be loaded The warning attributes report error_kind: image_source_not_found, source_kind: local, and the historical user-message index. A single request can produce a burst of identical warnings when several stale image markers exist. The native ZeroCode clipboard path already avoids this by marking source: clipboard, which makes the RPC attachment writer use the durable workspace copy. Host-generated clipboard files or other temporary images that arrive through the ordinary file path remain vulnerable because their markers prefer the original path. Expected behavior Persisted image markers should reference a durable attachment copy whenever the source path may be ephemeral. Since the RPC attachment writer already materializes every attachment into content-addressed workspace storage, persisted conversation history should
zeroclaw-labs/zeroclaw PR #10046 reports: Summary **Base branch:** master (all contributions). **Depends on #9580** — stacks on its approved head 964e463a5 so that head stays exactly what was reviewed; the isolated delta is one commit. **What changed and why:** three items from the maintainer verification pass on #9580, kept deliberately out of the approved head: **image_gen now requests the URL it validated.** parse_public_https_url canonicalizes the request URL with set_host after normalization, guarded for IP literals (mirroring http_request, whose guarded form is the correct sibling: normalize_domain returns unbracketed IPv6, which an unguarded set_host rejects). Previously a host that normalizes differently than Url::host_str (a leading-dot form) validated and pinned one host while reqwest re-resolved the original unvalidated one. **web_fetch's redirect boundary gains its missing end-to-end regression.** The Policy::custom closure moves byte-identically into a shared build_redirect_guarded_client constructor (production execute() and the tests call the same builder — exactly one Policy::custom exists in the file), and a two-loopback-server test drives a real 302: the cross-host hop must never reach the second server, the rejection must be attributed to redirect policy, and the Firecrawl fallback decision must be false from the real flag state. The redirect Location uses a literal address resolvable without the pin, so a permissive-policy mutation reaches the second server instead of failing at DNS — the
zeroclaw-labs/zeroclaw issue #10044 reports: Summary Let users promote, copy, and otherwise recover a selected queued ZeroCode message without first moving it back through the composer. Problem statement While a turn is running, Enter adds the current prompt to the outbound queue and Ctrl+Enter interrupts the active turn and sends immediately. If a user intended to interrupt but pressed Enter, the queued prompt has no direct **Send now** or **Copy** action. There is an existing recovery sequence: select the queued item, press Alt+E to move it back into the composer, then press Ctrl+Enter. This is difficult to discover, takes multiple steps, and is unavailable when the composer already contains a draft or pending attachments. Copying similarly requires moving the message out of the queue first. The queue already supports selecting, editing, and deleting individual items, so selected messages should expose a complete recovery surface. Proposed solution Add actions for the selected queued message: **Send now**: promote the selected item to the existing injection path, resume the queue, cancel the active turn when necessary, and dispatch the promoted item before ordinary pending items. **Copy**: copy the queued message text without removing, reordering, or otherwise mutating the item. **Edit** and **Delete**: retain the existing queue actions and expose them through the same interaction surface. Right-clicking a queued
Why it matters
Temporary paths become durable lies when memory records them as stable evidence. Image generation redirects and queued-message recovery add two more places where the runtime must preserve provenance across failure. 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-17. The tagged-release baseline was v0.8.4 published 2026-08-02T21:00:00Z. 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/zeroclaw-labs/zeroclaw/issues/10045. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/pull/10046 and https://github.com/zeroclaw-labs/zeroclaw/issues/10044. 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
Copy durable artifacts before persistence, store origin and final location separately, pin network destinations through redirects, and make queued recovery actions idempotent. 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.