# 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](/mcp/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](https://github.com/major7apps/pensyve/issues/217) · 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](https://github.com/major7apps/pensyve/issues/257) · 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](https://github.com/major7apps/pensyve/issues/107) · 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](https://github.com/major7apps/pensyve/issues/301) · 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](https://github.com/major7apps/pensyve/issues/284) · 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](https://github.com/major7apps/pensyve/issues/249) · 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](https://github.com/major7apps/pensyve/issues/94) · 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](https://github.com/major7apps/pensyve/issues/90) · 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](https://github.com/major7apps/pensyve/issues/285) · 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](https://github.com/major7apps/pensyve/issues/266) · 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](https://github.com/major7apps/pensyve/issues/265) · 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](https://github.com/major7apps/pensyve/issues/264) · 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](https://github.com/major7apps/pensyve/issues/246) · 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](https://github.com/major7apps/pensyve/issues/194) · 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](https://github.com/major7apps/pensyve/issues/187) · 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](https://github.com/major7apps/pensyve/issues/184) · 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](https://github.com/major7apps/pensyve/issues/183) · 2026-07-18 · closed · 0 comments

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