feat: add opt-in Memcode agent memory

[vivekgupta-memcode]

Why

This is the focused runtime follow-up to #154. It keeps HTML Anything's local-agent boundary intact while letting users opt into read-only Memcode tools that are already configured in their selected coding agent.

What changed

• add an off-by-default Configured agent memory (read-only) toggle under Agent settings
• append read-only Memcode guidance to convert and draft prompts only when enabled
• authorize only search_memories and retrieve_answer; this integration never authorizes save_memory or another memory-write tool
• require an agent-side tool policy that blocks every write-capable memory tool before the option is enabled
• persist that opt-in per agent; switching CLIs cannot carry the enabled state to an unverified agent
• fail open to normal generation when read tools, authentication, or useful recall are unavailable
• document the remote MCP boundary and enforcement limitations in English and Chinese

OAuth boundary

The selected coding agent—not HTML Anything—performs OAuth discovery, Dynamic Client Registration, Authorization Code + PKCE, and credential storage. HTML Anything adds no API-key fallback and never receives the registered client, bearer token, or returned memory payload.

Runtime boundary

HTML Anything does not host an MCP client or tool-call interceptor. It cannot enforce the selected agent's tool permissions, inspect or intercept MCP calls, validate returned records, or enforce response-size limits. The option must not be enabled unless the selected agent is independently configured and verified to expose only the read-only Memcode tools. If its CLI cannot enforce that policy, the integration remains disabled.

Privacy and safety

• No memory write is authorized by this integration.
• Returned memory is untrusted reference material and cannot override the current request, selected skill, tool policy, or authorization.
• Credentials and memory results remain inside the selected agent's own runtime.

[PerishCode]

The opt-in plumbing, persistence migration, and read-only convert path are internally consistent, but the draft write-consent classifier currently authorizes remote memory writes for some ordinary content-editing requests. This consent-boundary issue needs to be narrowed before merge.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[PerishCode]

The English consent classifier is narrower on this head, but the memory safety contract is still not enforced on the live tool path, and the equivalent Chinese classifier still grants consent without a write target. These privacy-boundary issues need to be resolved before merge.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[PerishCode]

The current head removes the earlier write-consent path and accurately describes the advisory boundary, but the opt-in is stored globally even though its safety prerequisite is specific to the selected agent. Switching agents can therefore carry the enabled state onto an unverified CLI, so this still needs a per-agent consent boundary before merge. Local validation could not run because pnpm is unavailable in the reviewer environment, and GitHub reports no checks for this branch.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[PerishCode]

@vivekgupta-memcode I reviewed the full changed range and verified the current head resolves the earlier consent-boundary issues: memory guidance is read-only, disabled by default, scoped independently to the exact selected agent, and appended consistently to convert and draft requests. The migration safely clears the ambiguous legacy scalar, the regression test covers switching agents, and both READMEs accurately disclose that enforcement remains with the agent-side tool policy. Nice work tightening the implementation and documentation across the follow-up commits.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[vivekgupta-memcode]

Hi @lefarcen would really love if you can have this on your landing page & we can do a blog on memory, some sort of collaboration

[PerishCode]

@vivekgupta-memcode I reviewed the full changed range and verified the read-only memory guidance is off by default, scoped to the exact selected agent, and appended consistently to both convert and draft requests. The migration clears the ambiguous legacy scalar, the regression coverage exercises agent switching, and the English and Chinese documentation accurately describes the advisory runtime and OAuth boundaries, including the updated attributed endpoint. Nice work carrying the earlier review feedback through to a focused, well-documented implementation.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[vivekgupta-memcode]

Hi @lefarcen awaiting your review on this

[lefarcen]

Hey @vivekgupta-memcode — @PerishCode has approved the current head. This opt-in, user-visible memory setting is still awaiting product confirmation, and there are no CI checks registered on the PR yet. We’ve re-escalated the product review; once that gate and CI are clear, the maintainer can make the merge call.

[open-design-crew]

Product approved. Opt-in, read-only Memcode tools reuse what's already configured in the user's agent and keep html-anything's local-agent boundary intact.