Could AIO Sandbox expose durable agent memory alongside MCP?

Hi, I’m Vivek Gupta, Founder & CEO at [MemCode](https://memcode.in). AIO Sandbox unifies browser, shell, file, VSCode, Jupyter, and MCP services inside one agent-ready environment, which makes it useful for workflows that span many tools. Because the container and its working state may be recreated, agents also need a separate way to carry user preferences, task decisions, and learned tool context across sandbox lifecycles.

Would you consider documenting an optional MemCode integration through the existing MCP service or SDK surface? The adapter could keep memory outside the ephemeral execution environment, use explicit user/workspace/task scopes, and make every read/write visible and opt-in. It should preserve the sandbox security boundary, support retention/export/deletion, and fail open to the current sandbox behavior if the memory service is disabled or unreachable.

I’d be happy to build a minimal Python or TypeScript example that runs against the AIO Sandbox API and MCP endpoint, with the data-flow and security assumptions documented. If there is a preferred extension path, I can follow it in a focused PR or discuss it briefly with the maintainers.

Start by reviewing the existing AIO Sandbox API and MCP endpoint surfaces to identify the preferred extension path. The scope needs maintainer agreement before implementation; done would be a focused example with documented data flow, security assumptions, explicit scopes, opt-in behavior, retention/export/deletion, and disabled-service fallback.

Written by the indexing model from the issue text.