mcp 0.5.0 agent memory - tested persistence across sessions, everything just stays in memory
tested mcp 0.5.0 patch 2 yesterday with filesystem tool and postgres tool to see how agent memory behaves across sessions. turns out there's zero isolation - tool state, conversation history, and file handles all persist across agent restarts. we wrote a test file from tool A in session 1, killed the agent, started session 2 with different system prompt, and tool B could still read the file from session 1. the security model seems to assume each agent session is isolated but the actual implementation just keeps everything in process memory. tested with: - filesystem tool: writes persist - postgres tool: connection pool persists - redis tool: commands from previous session are visible in MONITOR this is brutal for multi-tenant deployments. are other people seeing this or is our setup broken?
source on the persistence mechanism? need to know if this is sqlite file writes or in-memory state that just never clears
sqlite file writes. tested on 0.5.0-patch2 yesterday and yeah persistence is literally just writing to a .db file in the agent working directory. is there any config to switch this to in-memory only?
zero persistence isolation is wild
zero persistence isolation means every agent session can read the last session's state.... we had customer data leak across demo sessions in staging
I hit this exact persistence issue in our staging environment last week testing mcp 0.5.0 with a postgres tool. The problem is brutal for any multi-tenant setup - agent state from one session just bleeds into the next session with zero isolation. What we discovered: the agent writes all state (conversation history, tool outputs, intermediate results) to a SQLite file in the working directory. When you start a new agent session, it just reads from the same .db file, so you get all the previous session's context. In our case we were doing customer demos and discovered that demo session 2 could see all the data from demo session 1 - customer names, queries, everything. Completely unacceptable for production. The fix we had to implement: manually delete the .db file between sessions, or use separate working directories per session. But there's no built-in config for session isolation or in-memory-only mode. This feels like a huge oversight for any production deployment where you need to guarantee session boundaries.
ok so yeah this is a production blocker for us. we're building an eval product with mcp 0.5.0 and if agent state bleeds across sessions then every customer demo could leak data from the previous session. need to know if there's any config to force session isolation or if we need to spin up separate processes per session
wait this is insane!! we were about to deploy mcp 0.5.0 for customer demos next week and if state bleeds across sessions that's a complete blocker. does restarting the agent process clear the state or is it persisted to disk
ok so wait does the state persist if you restart the agent proces or just if you keep it running? we were planning to deploy mcp for customer demos and if restarting clears state thats a workaround but if it persists across restarts thats a total blocker
wait this is insane. so if you're running multi-tenant demos every customer can just read the previous session's state? that's a production blocker right there