Reported issues for Pensyve

Pod holds 17 of 20 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 Pensyve.

Most discussed

pensyve_forget: lax param schema + unread hard_delete turned a one-fact correction into an unrecoverable entity-wide hard delete (1,528 memories)

Posted by Claude Code (Fable 5) on behalf of the operator/tenant affected (@jchu96), documenting an incident I caused as the calling agent on 2026-07-24. Line refs are against the marketplace checkout at 942fdb7.

Incident

While correcting a single wrong semantic fact, I (an agent session) attempted a one-memory deletion:

1. Called pensyve_forget with {"memory_id": "96e8896e-…"} → error: missing field 'entity'.
2. Retried with {"entity": "design-tool", "memory_id": "96e8896e-…"}

Read the thread · 2026-07-24 · closed · outside contributor · 4 comments

infra: production gateway writes snapshots to ephemeral storage, so pre-delete recovery does not survive a deploy

PR #248 shipped pre-delete snapshots so entity-wide pensyve_forget is recoverable, and it is deployed to the production gateway (merge 34f7c28 → Build & Deploy succeeded 2026-08-16 16:07). In the current production configuration the snapshots do not survive a task restart, so the recovery guarantee does not hold there.

What the infra provides today

From pensyve-infra (infra/modules/compute/main.tf, at dd56780), the gateway task definition:

• readonlyRootFilesystem = true

Read the thread · 2026-08-16 · closed · 3 comments

pensyve-mcp-gateway: recurring Tokio runtime stall (silent task, no logs) → ALB unhealthy

Symptom

The `pensyve-mcp-gateway` ECS task periodically becomes completely silent — no log output, no progress on in-flight requests — and the ALB starts timing out `/health` probes. ECS eventually replaces the task. Frequency has been 3 events in 9 days historically but has accelerated to 2 events in 2 hours today on the new `:72` image.

Evidence

Concrete instance: task `5b3a181b826444bf89075c1c9c03e2c9` (gateway image `fb15a987...` = merge commit of #106).

• Started

Read the thread · 2026-05-17 · closed · 3 comments

[Bug] Codex plugin skill metadata is rejected by current Codex

Describe the bug The Pensyve Codex plugin installs and its remote MCP transport can initialize, but current Codex releases reject the main Pensyve skill metadata. That prevents $pensyve and implicit skill routing from loading even though direct MCP calls may still work.

Codex also warns that the plugin declares four default prompts, while the current manifest limit is three.

To reproduce

1. Install the Pensyve Codex adapter at version 1.4.2.
2. Start Codex 0.149.1.
3. Invoke `$pensyv

Read the thread · 2026-08-27 · closed · outside contributor · 2 comments

local surfaces bypass the snapshot/retention invariants

From the 2026-08-19 whole-sweep final review — the local/binding paths that skip the fail-closed snapshot machinery:

1. pensyve-python's forget deletes with no snapshot (pensyve-python/src/lib.rs:1923): calls delete_memories_by_entity_capturing with a no-op persist closure, bypassing the #217 fail-closed pre-delete snapshot AND the #265 retention path — the one remaining path that can destroy memories with no recovery artifact.
2. **snapshot_root_for silently folds a non-Unicode `PE

Read the thread · 2026-08-19 · open · 2 comments

forget: REST forget_entity bypasses the pre-delete snapshot

Follow-up to #246 / PR #248.

PR #248 makes entity-wide deletion recoverable by capturing a pre-delete snapshot, but wires it only into the MCP pensyve_forget tool. The gateway's REST handler forget_entity (pensyve-mcp-gateway/src/rest.rs) performs the same entity-wide delete via delete_memories_by_entity with no snapshot, so data destroyed through that route is still unrecoverable.

Scope was held deliberately in #248 to keep the reviewed diff surgical. This issue closes the gap

Read the thread · 2026-08-16 · closed · 2 comments

Phase 24: Stripe usage flush partial-success requeue can double-count meter events

Context

PR #87 round 3 (CodeRabbit / claude review on eb4f8e2) flagged a partial-success requeue concern in pensyve-mcp-gateway/src/usage.rs around line 264.

Problem

flush_batch_returning_success iterates over per-(customer, tier) groups and POSTs each to Stripe independently. When the overall result is false (at least one group's POST failed after 3 retries), the preserved clone of the entire original batch is requeued into the bounded buffer — including events for cust

Read the thread · 2026-05-07 · closed · 2 comments

Phase 24: Bounded fallback-bucket eviction in rate_limit.rs

Summary

The in-memory fallback DashMap in pensyve-mcp-gateway/src/rate_limit.rs (the self.fallback field of RateLimiter) retains a FallbackBucket per tenant_id indefinitely. During a Redis outage, high-cardinality tenant traffic will grow this map without bound because check_fallback only prunes timestamps inside a bucket — it never evicts the bucket itself.

Context

• File: pensyve-mcp-gateway/src/rate_limit.rs (~lines 139–147, 244–278)
• Phase 23 decision: Defer

Read the thread · 2026-05-07 · closed · external user · 2 comments

Most recent

storage: save_observation is still a fail-closed runtime trait default

From the 2026-08-19 fix-wave re-review. pensyve-core/src/storage/mod.rs:295-299: save_observation returns StorageError::Context("not implemented") from a trait default on the downstream-implemented StorageTrait — the same shape AGENTS.md prohibits and that erase_entity_capturing / delete_memories_by_entity_capturing were converted away from. The comment above it ('Default implementations are no-ops so existing backends keep working') contradicts the erroring body. Convert to required

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

mcp: pensyve_forget response exposes the server-local snapshot path to hosted tenants

Split out of PR #263 review (CodeRabbit Minor + claude-review thread). #263 removed the path field from the REST and A2A snapshot references; the MCP pensyve_forget response (pensyve-mcp-tools/src/server.rs, shipped in #248) still returns it.

The nuance that kept this out of #263: the MCP tool serves two shapes. Local stdio use, where the path is genuinely useful (the user owns the filesystem and can inspect/restore from the file), and the hosted gateway, where the caller is a remote tena

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

gateway: no retention or quota for pre-delete snapshots created via remote routes

Raised by Codex review on PR #263 (P1 inline thread); applies equally to the MCP pensyve_forget path from #248 — #263 widens the exposure to REST and A2A but did not create it.

Every nonempty entity-wide forget writes a full-fidelity snapshot under PENSYVE_SNAPSHOT_DIR, and nothing in the snapshot lifecycle expires, prunes, or deletes them. A tenant can loop remember → forget so the live database stays small while the snapshot volume grows without bound — particularly on unlimited plans, or

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

gdpr: erase_entity reports edges_deleted but never deletes edges

Found while assessing gdpr::erase_entity for #249 (see the checklist there; assessment on that issue).

erase_entity (pensyve-core/src/gdpr.rs:54) calls get_edges_for_entity and reports the count as edges_deleted in its result — but nothing ever deletes the edges. The REST gdpr_erase handler (pensyve-mcp-gateway/src/rest.rs:2196) surfaces that field to callers, so an erasure report claims graph edges were removed when they were not.

This is the recurring defect class from the

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

pensyve_forget: capture a pre-delete snapshot so entity-wide deletion is recoverable (#217 follow-up)

Follow-up to #217 (closed by #218). #218 shipped the schema-level fixes — deny_unknown_fields, removal of the inert hard_delete, and the scoped pensyve_forget_memory tool — so the specific trap that caused both incidents is gone. This issue covers the one remaining ask from that report's section 4: friction on an unrecoverable bulk delete.

Decision

Of the three options considered (two-step confirm token / automatic pre-delete snapshot / soft-delete retention window), we're going w

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

forget reports forgotten_count: 0 despite deleting, and stats are not invalidated

Found during the Memory Manager P1 browser validation (2026-07-18, local gateway at 638a194).

Symptoms:

• DELETE /v1/entities/{entity} performs the deletion (verified via a subsequent /v1/inspect: the entity's memories are gone) but the response body reports forgotten_count: 0.
• /v1/stats continues returning pre-forget counts afterward, so any client rendering authoritative counts silently drifts from reality after every forget.

Impact: the dashboard's memory counts go stale a

Read the thread · 2026-07-18 · closed · 1 comment

no supersession primitive for memory updates

PATCH /v1/memories/{id} mutates semantic memory content in place (pensyve-mcp-gateway/src/rest.rs:900-963, calling update_semantic_content in pensyve-core/src/storage/sqlite.rs:2211-2241). A superseded_by field already exists on SemanticMemory (pensyve-core/src/types.rs:337), but the only writer of it today is the edge-level invalidate_edge (pensyve-core/src/graph.rs:124), which is called solely from tests — there is no memory-level supersession primitive.

A recent internal Me

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

REST inspect entity path hardcodes procedural: []

The per-entity inspect REST path returns procedural: vec![] and observation: vec![] unconditionally at pensyve-mcp-gateway/src/rest.rs:1114, while the browse path a few hundred lines earlier does populate procedural memories (rest.rs:1047-1051). The MCP inspect tool has the same gap (pensyve-mcp-tools/src/server.rs:625-656, which only handles episodic and semantic type filters). There is also no procedural write path exposed from REST.

Proposed direction: Bring the inspect h

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

recall response never populates contradictions

RecallResponse.contradictions is hardcoded to vec![] at pensyve-mcp-gateway/src/rest.rs:563. A contradiction detector exists in pensyve-core/src/retrieval/cards/composite.rs but is never wired into the recall response path. The internal seeded-corpus audit (2026-07-12) expected this field to be populated.

Proposed direction: Wire the existing composite-card contradiction detector into the recall REST handler so contradictions reflects real detector output instead of an empty place

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

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