# 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](/mcp/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](https://github.com/tenequm/pond/issues/195) · 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](https://github.com/tenequm/pond/issues/170) · 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](https://github.com/tenequm/pond/issues/111) · 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:

| Component | MiB | Reclaimable? |
|---|---|---|
| Live Lance caches (index IVF/PQ + FTS post

[Read the thread](https://github.com/tenequm/pond/issues/61) · 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](https://github.com/tenequm/pond/issues/60) · 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](https://github.com/tenequm/pond/issues/33) · 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](https://github.com/tenequm/pond/issues/167) · 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](https://github.com/tenequm/pond/issues/166) · 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](https://github.com/tenequm/pond/blob/main/docs/researches/2608-12-read-path-where-time-goes.md)): 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](https://github.com/tenequm/pond/issues/165) · 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](https://github.com/tenequm/pond/issues/131) · 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](https://github.com/tenequm/pond/issues/89) · 2026-07-03 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/tenequm/pond/issues).