What happened?
When calling mind_context(action: clear) to remove stale context entries, the tool returns a success confirmation (e.g., Context entry deleted: session) but the entries remain in the database. Subsequent calls to mind_context(action: read) show all entries still present and unchanged.
Multiple sequential clear calls were attempted against entries with different scope values (session, intimate, current). Each call returned a success message, but a follow-up read showed zero entries were actually removed.
Manual deletion via the Cloudflare D1 console (SQL DELETE FROM context_entries WHERE id = '...') worked correctly — confirming the entries are normal D1 rows and the issue is in the MCP tool's delete logic, not in the database itself.
What did you expect?
After mind_context(action: clear, id: "session") returns Context entry deleted: session, the corresponding row should be removed from the context_entries table. Subsequent mind_context(action: read) should no longer include that entry.
Steps to reproduce
- Confirm context entries exist:
mind_context(action: read)
Result: Multiple entries returned (e.g., 11 entries with scopes session, intimate, current)
- Attempt to clear an entry:
mind_context(action: clear, id: "session")
Result: Context entry deleted: session
- Read context again:
mind_context(action: read)
Result: Same entries as step 1 — nothing was removed.
-
Repeat steps 2-3 with different scope values (intimate, current). Same behavior — success confirmation, no actual deletion.
-
Manually delete via D1 console:
DELETE FROM context_entries WHERE id = 'ctx-20260205201250-bn1i';
Result: Entry is actually removed. Confirmed via both D1 console and mind_context(action: read).
Environment
- Resonant Mind version: v3.2.0
- Storage backend: D1 (SQLite) + Vectorize
- MCP client: Claude.ai (via MCP connector)
- Cloudflare Workers
Additional context
The clear action appears to match entries by the scope column value (e.g., "session") rather than by the unique id column (e.g., "ctx-20260205201250-bn1i"). When multiple entries share the same scope, the first call may succeed for one entry, but subsequent calls against the same scope fail silently while still returning success messages.
The root issue may be that the delete operation is not being committed to the D1 database, or that the tool is operating on an in-memory representation that doesn't sync back to persistent storage.
What happened?
When calling
mind_context(action: clear)to remove stale context entries, the tool returns a success confirmation (e.g.,Context entry deleted: session) but the entries remain in the database. Subsequent calls tomind_context(action: read)show all entries still present and unchanged.Multiple sequential clear calls were attempted against entries with different scope values (
session,intimate,current). Each call returned a success message, but a follow-up read showed zero entries were actually removed.Manual deletion via the Cloudflare D1 console (SQL
DELETE FROM context_entries WHERE id = '...') worked correctly — confirming the entries are normal D1 rows and the issue is in the MCP tool's delete logic, not in the database itself.What did you expect?
After
mind_context(action: clear, id: "session")returnsContext entry deleted: session, the corresponding row should be removed from thecontext_entriestable. Subsequentmind_context(action: read)should no longer include that entry.Steps to reproduce
Result: Multiple entries returned (e.g., 11 entries with scopes
session,intimate,current)Result:
Context entry deleted: sessionResult: Same entries as step 1 — nothing was removed.
Repeat steps 2-3 with different scope values (
intimate,current). Same behavior — success confirmation, no actual deletion.Manually delete via D1 console:
Result: Entry is actually removed. Confirmed via both D1 console and
mind_context(action: read).Environment
Additional context
The
clearaction appears to match entries by thescopecolumn value (e.g., "session") rather than by the uniqueidcolumn (e.g., "ctx-20260205201250-bn1i"). When multiple entries share the same scope, the first call may succeed for one entry, but subsequent calls against the same scope fail silently while still returning success messages.The root issue may be that the delete operation is not being committed to the D1 database, or that the tool is operating on an in-memory representation that doesn't sync back to persistent storage.