NanoClaw reports show compaction can grow the archive it should tame

The archive report describes a process that can defeat the purpose of compaction. Each firing builds one in-memory string from the full message array and writes a complete Markdown file. When no cached summary exists, minute-based fallback names can produce another distinct file on the next firing. The reporter connects frequent full rewrites to disk growth and possible peak-memory pressure; the exact causal strength must remain attributed, not promoted into a universal outage claim.

The configuration report makes emergency tuning harder. Container-side code reads the documented overrides, but the provider’s host-to-container environment contribution does not forward them. The report says the gap is present in v2.2.0, v2.3.0 and main. A source-level ‘operator-overridable’ comment is therefore not proof that an operator can change the running behavior from outside the container.

The facts

- Issue #3716, filed September 4, reports PreCompact archives rewriting the full conversation rather than appending new messages. - The report distinguishes unbounded Markdown archives from separately size- and age-bounded JSONL resume transcripts. - Issue #3714 says three documented compaction/rotation environment overrides are absent inside session containers. - The reporter observed two compactions in 17 minutes near 132k tokens, with compacting turns taking over six minutes in that installation. - PR #3710 reports roughly 355 temporary directories left after a test run and a zero-delta result after scoped cleanup on its verification checkout.

Why it matters

A long-lived agent accumulates more than conversation tokens. Archives, resume transcripts, dependency caches and test fixtures have distinct owners and retention rules. Bounding one does not bound the others. The test-cleanup proposal is not evidence of the same production failure, but it supplies an independently described example of persistent residue: hundreds of directories survive until reboot or a delayed system cleanup, and tmpfs turns that residue into RAM consumption.

Current

Inspected on 2026-09-06. The NanoClaw stable-release baseline is v2.3.0 published 2026-08-24T11:45:32Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is nanocoai/nanoclaw issue #3716 (https://github.com/nanocoai/nanoclaw/issues/3716). Supporting context comes from nanocoai/nanoclaw issue #3714 (https://github.com/nanocoai/nanoclaw/issues/3714); nanocoai/nanoclaw PR #3710 (https://github.com/nanocoai/nanoclaw/pull/3710). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Measure archive size, firing frequency and peak memory separately before choosing a remedy. Verify that a configured override is present in the actual container without dumping unrelated environment values. Keep cleanup scoped to artifacts the process created; the test proposal uses afterAll where fixtures outlive individual cases and afterEach only where ownership permits. Do not treat deleting conversation history or renaming a live resume transcript as a routine fix merely because an issue mentions it as a workaround.

Caveat

Both production reports and the cleanup PR were open. The archive reporter used a fork of main, and the test author required a local dependency pin for an arm64 verification run. These observations justify investigation, not a claim that every NanoClaw installation is leaking or that a repair has shipped.