`memwal_health` reports `ok` during a total write-path outage, and the write error leaks an internal `localhost:9000` address that misleads users into debugging their own machine

[Tolex081]

MemWal bug report — ready to paste

File at: https://github.com/MystenLabs/MemWal/issues

Checked against open issues #575–#593 — not a duplicate. The nearest is #580 (post-login
credential refresh → 401), which is an auth failure. This is not auth: login was valid
and reads kept working throughout.

Remove the account identifiers at the bottom if you'd rather not publish them. They only
help the engineers find server logs.

---

Title

memwal_health reports ok during a total write-path outage, and the write error leaks an internal localhost:9000 address that misleads users into debugging their own machine

---

Body

Summary

During a study session on 2026-08-16 the write path failed almost completely — 10 of 12
memwal_remember calls were lost, only 2 persisted. Reads were unaffected: memwal_recall
and decryption worked normally the entire time.

Two things made this much worse than a plain outage:

1. memwal_health returned ok throughout, while writes were failing 100%. The health
   check does not cover the write path, so a green result is not evidence that memory is
   working.
2. The write error surfaced http://localhost:9000/seal/encrypt. That reads as a service
   on the user's own machine. It is not one — the published npm client contains no reference
   to port 9000 or to seal anywhere. The agent assisting me believed it and instructed me to
   restart a local process that does not exist on my computer.

Individually each is a papercut. Together they mean a user can lose data silently, be told by
the health check that everything is fine, and then waste an hour debugging their own setup.

Environment

• @mysten-incubation/memwal-mcp 0.0.6 (stdio MCP server, Claude Code)
• Relayer https://relayer.memory.walrus.xyz, reported version 0.1.0
• Node v22.17.1, Windows 11
• Date/time: 2026-08-16, approx. 18:00–19:00 UTC+1

What happened

1. Ran a study session that generated 12 memories to write across namespaces
   move-core, sui-obj, move-sec, exam-intel.

2. memwal_remember calls began timing out. The agent backed off rather than retrying hard.

3. memwal_health was called and returned ok (relayer up, v0.1.0).

4. memwal_recall and memwal_restore continued to work correctly against existing data,
   including decryption.

5. Final state, verified by recall + restore per namespace:

   namespace	stored
   move-core	0
   sui-obj	1
   move-sec	1
   exam-intel	0

   2 of 12 written. 10 lost. There is no local queue, so the unsent entries existed only
   in the chat session.

6. The error text referenced http://localhost:9000/seal/encrypt.

Why the error message is a bug in its own right

localhost in a user-facing error means "your machine" to every reader. Encryption in this
architecture happens server-side — the client's own README describes the package as a bridge
to the hosted relayer, which handles Seal encryption and Walrus storage.

I verified the published 0.0.6 bundle: it contains no occurrence of 9000 and no
occurrence of seal. Its only local addresses are the loopback listener used for the browser
login callback and a localhost:5173 dev URL.

So the address cannot be acted on by the user, and it actively points them in the wrong
direction. A capable agent read it, concluded a local sidecar had died, and told me to restart
it. There was nothing to restart.

Impact

• Silent data loss. Writes fail, nothing is queued locally, and the memories are gone once
  the session ends.
• The obvious diagnostic lies. health is the tool a user reaches for, and it said ok.
• The error sends users the wrong way. Time lost debugging a non-existent local process.

For a memory product this is the worst failure shape: the user believes their data is safe
when it is not.

Suggested fixes

1. Make memwal_health cover the write path end to end — or return a per-component
   status (relayer, encryption, storage) rather than a single ok. A health check that
   passes during a total write outage is worse than none, because it is trusted.
2. Stop leaking internal hostnames into client-facing errors. Map them to something the
   user can act on: "Encryption service unavailable on the Walrus relayer — this is
   server-side, retry shortly." Explicitly say it is not the user's machine.
3. Consider a local retry queue for failed writes, so a transient outage does not destroy
   captured memories when the session closes.

Reproducibility

I cannot trigger the outage on demand — it was an incident window, and writes recovered later
the same evening. Server logs for the account below should show it.

Items 1 and 2 do not depend on reproducing the outage. Both are constant properties of the
current design: health never checks the write path, and the error string is emitted whenever
that failure occurs.

• Delegate public key: 7aa33f567bb3c3d64d6f97f6b5fa1a38d92f0193a7920dc94d5f1fc0d1d3779f
• MemWal account ID: 0xe9455a5452488deb949d015c68aadfb333e1617ccb9446ec3c17cc42d77a67d5

[github-actions]

Thank you for opening this issue, a team member will review it shortly.