Reported issues for pond

Pod holds 11 of 11 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to pond.

Most discussed

pond serve never stops when a supervisor asks it to

Follow-up to #194. Two separate problems with the same symptom: a supervised pond serve is always killed rather than stopped. Both reproduce against the v0.16.3 release binary in a container, serve --transport http --host 0.0.0.0, with pond as PID 1.

1. SIGTERM is ignored

transport.rs::shutdown_signal awaits tokio::signal::ctrl_c(), which on unix is SIGINT alone. Container runtimes, systemd and orchestrators all stop a process with SIGTERM, and a process running as PID 1 gets no def

Read the thread · 2026-08-29 · open · outside contributor · 2 comments

feature: letta-code adapter - sessions in ~/.letta/transcripts are not captured

Requested by a letta-code user on X who runs letta as the orchestrator with codex, pi, claude-code, and omp workers: https://x.com/kylelittle/status/2090858874626572337. Four of those already have adapters; this issue specs the letta-code one. React with 👍 if you want this adapter - reactions decide which adapter ships next.

Source of record

~/.letta/transcripts/<agentId>/<conversationId>/transcript.jsonl - the append-only client-side transcript letta-code writes for every conversation. R

Read the thread · 2026-08-21 · closed · 1 comment

pond serve leaks memory until OOM-killed (0.13.2): 157 MB -> 3.6 GB RSS over ~5 days

pond serve grows unbounded until the kernel OOM-kills it. On a 15 GB host it reached 5.5 GB RSS and was killed by the OOM killer; after an automatic restart it climbed back to 3.6 GB RSS + 3.2 GB swap over the next 4.9 days. pond mcp shows the same pattern independently.

Version

pond 0.13.2 (cc94b7d x86_64-linux)

Confirmed the leaking process was running this build (binary mtime predates process start), so this is not a stale-binary artifact.

Environment

• Ubuntu 24.04.4 L

Read the thread · 2026-07-20 · open · 1 comment

memory: reduce idle RAM of pond mcp toward <500 MiB (stream rowmap build, f16 model)

Goal

Bring idle RAM of a long-lived pond mcp server toward the <500 MiB target. Peak stays comfortably under the 2 GiB ceiling.

Measured baseline (real 2.1M-message corpus, local FS)

cargo bench --bench serve_mem_bench after serving fts + vector + sql + get, model idle-unloaded:

• idle floor: 877 MiB phys_footprint (the macOS "Memory"/Jetsam metric)

vmmap anatomy of that floor:

Read the thread · 2026-06-19 · open · 1 comment

pond as a third-party session manager: Strands Agents (SessionRepository) + Claude Agent SDK (SessionStore)

Context capture from the 2026-06-17 research session. Goal: design pond so it can be contributed as a third-party session manager - to Strands Agents (their community catalog) and to the Claude Agent SDK - riding on the in-flight durability/perf/live-write/erasure work rather than as a separate rewrite.

The two integration seams (both thin Python shims over pond's HTTP API)

Strands: implement SessionRepository, not SessionManager

Strands has two seams. SessionManager = full li

Read the thread · 2026-06-17 · open · 1 comment

claude-code adapter: workflow journal.jsonl wrongly flagged as 'unrecognized subagent transcript layout'

Summary

pond sync reports errors (8 err) and prints a scary "update pond and re-run pond sync" message for every Claude Code workflow journal file:

[11:34:57] claude-code skip  .../subagents/workflows/wf_030e6487-da6/journal.jsonl: subagent transcript layout not recognized by this pond version; skipped so it is not merged into the parent session - update pond and re-run `pond sync`
... (8 such lines)
sync claude-code  ... 8 err

This is a false positive. `journal.jsonl

Read the thread · 2026-06-04 · closed · 1 comment

redaction on outbound paths (copy, export, resume) - not at ingest

Why

Secrets land in agent sessions: API keys pasted into prompts, tokens in tool output, scheme://user:pass@host URLs. pond stores sessions value-complete and never pruned, so the question "what happens to a secret in my archive" needs a deliberate answer.

Redacting at ingest is the wrong layer for an archive: it destroys data in the one place whose promise is losslessness, and it does nothing about the original exposure - the key already went to the model and sits in the harness's ow

Read the thread · 2026-08-21 · open · 0 comments

namespaces: keep work and personal sessions apart, scope what each agent can recall

Why

The wire protocol already carries an opaque namespace (spec 7.3) and the substrate has a catalog seam for it (3.2 lance-chokepoints-catalog), but a personal pond has exactly one namespace and nothing enforces separation. Two concrete needs:

• Work vs personal. A contractor's client sessions must not mix with personal ones in the same store, and an agent working on the client's repo must not be able to recall personal sessions (or the reverse). Today the only answer is two separa

Read the thread · 2026-08-21 · open · 0 comments

Most recent

perf(read): remote store reads - parts residency, FTS prewarm, long-lived serve topology

Why

Measured over 30 days against a remote S3 store (2608-12 read-path doc): 77% of all pond MCP calls took over 5 s; pond_search p50 10 s; before #141 not one pond_get_session or pond_get_message finished under 5 s. "Your own S3 bucket" is the differentiator, so the remote read path has to feel local.

#141 (v0.14.9) landed the two biggest items - rowmap-served message-id resolution and g

Read the thread · 2026-08-21 · open · 0 comments

Regression test: stdout purity for stdio MCP transport

Why

The stdout-is-only-JSON-RPC invariant is load-bearing for every stdio MCP client, silent when broken, and currently guarded only by convention: nothing in CI asserts it. PR #129's first revision moved all tracing output to stdout (fmt::layer() defaults to stdout) and would have merged green - the corruption was caught only in review, measured at 9 stray log lines interleaved around the initialize response (RUST_LOG=info), and 281 lines mixed into pond status -vv output. A comment

Read the thread · 2026-07-28 · open · 0 comments

Remote-store SQL analytics over parts.variant_data time out: compress JSON columns + materialize tool columns

Symptom

On a remote (S3) store, corpus-wide tool-call analytics in pond_sql_query hit the 30s timeout guard (QUERY_TIMEOUT, src/sql.rs). This includes the schema doc's own flagship worked example ("tool usage and failure rates over the last week", src/transport.rs schema resource), which fails even scoped to 7 days. Even a plain GROUP BY json_get_string(variant_data, 'name') over all tool_call parts times out.

Found during an MCP stress test (2026-07-03) against the real corpus: 1

Read the thread · 2026-07-03 · closed · 0 comments

The remaining reports are on the project's issue tracker.