[BUG] Desktop sessions with local file access have no memory tool at all — file access and the rules governing it are mutually exclusive

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On the same account, on the same day, the two surfaces of the merged product are complementary rather than overlapping. Measured repeatedly between 15 and 21 August 2026:

| Surface | memory tool in the session's tool list | local files via MCP |
|---|---|---|
| claude.ai in the browser | yes — a write succeeded on 18 Aug | no — a browser session cannot reach a local stdio MCP server |
| Desktop session with access to the local machine | no — no memory tool at all, neither read nor write | yes |

There is no configuration in which both are available at once. The daily choice is: work with the knowledge base but without the rules that govern its use, or work with the rules but without the material they refer to.

The capability is absent, not declined. Instructing the session directly to apply a stored rule produces no refusal and no error — there is simply no tool. And nothing in either interface indicates which of the two states the current session is in.

Why the silence is the actual defect

Memory is where standing protective rules live: "never downgrade the MCP server", "never send mail on my behalf", "the vault root is X, always work on the whole vault". When a session does not load them, they are missing precisely where files are being changed and mail is being sent, and there is no signal of any kind. From the outside it is indistinguishable from an explicit instruction being deliberately ignored.

Three measured consequences

15 August. A standing rule forbidding a downgrade of the MCP server was in memory. The session had no memory. The downgrade happened, did not fix the failing path, and killed the one access path that still worked. The rollback did not restore it.

18 August. A session composed and sent an email on the account owner's behalf, against a standing rule that mail is delivered as copy-ready text and never sent. The resulting support thread then defended a payments policy against a request the user had never written.

21 August. Six consecutive failed attempts to hand a project over to a new chat. The rule governing that handover is a file inside the connected vault — the session had file access and could have read it, but had no memory that the rule existed, and no signal that memory was absent. Attempt 4 told the user to "continue without the vault". Attempt 5 wrote an instruction telling the next session not to request folder access, the exact inverse of the stored rule. Only on attempt 6 was the governance file read directly.

Why this is not a duplicate of #55842

#55842 (open since 3 May 2026, labelled enhancement, no maintainer response) is about state not carrying across surfaces. This report is narrower and is a bug rather than a missing feature: within a single session the capability is absent from the tool list, and the UI asserts nothing about it. A user cannot distinguish a session that ignored a rule from a session that never had it.

The workaround found so far is to move protective rules out of memory and into a Skill, because Skills load in both surfaces and memory does not. That is a workaround for a defect, not a design.

What Should Happen?

Two things, in order of how much they would help:

1. Make the state visible. A session should state whether memory is loaded. If the memory tool is not in the tool list, the interface should say so before work starts, rather than leaving the user to infer it from rules being silently disregarded. This alone would have prevented all three incidents above.

1. Decouple the two capabilities. What enables a session to reach local files must not be what removes its memory. A desktop session with a connected folder should carry memory exactly as a browser chat does.

Error Messages/Logs

None. That is the finding.

No error is emitted, no warning is shown, and no tool-registration failure is logged. The memory tool is simply not in the session's tool list, and the interface makes no statement about it.

Steps to Reproduce

1. On one account, open a chat on claude.ai in the browser. Ask the session for its available tools, or ask it to write a memory entry.

-> The memory tool is present; the write succeeds.

1. In the desktop app, start a session that has access to a local folder (a connected folder / local stdio MCP server). Ask that session for its tool list.

-> No memory tool at all, neither read nor write.

1. In that same desktop session, instruct it directly to apply a rule stored in memory.

-> It cannot. Not a refusal and not an error: the capability is absent.

1. Compare the two interfaces.

-> Neither one indicates which of the two states the session is in.

Reproduced across many sessions between 15 and 21 August 2026, and on a second machine. Same account throughout.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop app 1.30096.5 (14 Aug 2026 build)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related issues

• #55842 — memory, files, skills and connectors not shared across the merged surfaces. Open since 3 May 2026, labelled enhancement, no maintainer response. A comment carrying this measurement was posted there on 18 Aug 2026; filing separately because "capability absent with no signal" is a defect rather than a missing feature.
• #80094 — official filesystem MCP server unusable since 14 Aug 2026. Same wave of regressions, reported separately.

Context

• Max subscription, macOS, desktop app build 1.30096.5.
• That 14 Aug build declares "No user-facing changes" in all four changelog sections, while the merge default was flipped in v1.26832.0 on 6 Aug and the folder permission model rebuilt in that same release.
• Roughly ten user-authored skills had to be rewritten after the merge because behaviour they depended on had been removed.

Minimum ask

If decoupling is out of scope, at least surface the state. One line telling the user whether memory is loaded turns a silent, unattributable failure into something that can be worked around.