[BUG] Fable 5 confabulates external concurrent writes during filesystem MCP operations, session crashes and disappears

Open 💬 1 comment Opened Jun 12, 2026 by Option2Ghost

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?

Model: Claude Fable 5

Interface: Claude Desktop (Windows 11)

MCPs active: Filesystem MCP (Node.js), Revit MCP Technical Preview

Date: June 12, 2026
Behavior:
During a session performing sequential filesystem MCP write operations (creating a new file, renaming two existing files, and updating references across five protocol files), the model began claiming that an external party was simultaneously editing the same files. No other session was active. The confabulation escalated and the session then crashed and disappeared from the conversation list entirely. It no longer appears in chat history.
The work the model produced before crashing was correct. All file writes completed successfully. The misattribution of its own MCP write operations to an external source is the bug.
Evidence:
Filesystem timestamps on the following files confirm the session was active and writing correctly immediately before the crash:

KMS_INDEX.txt (created this session)
ACTIVE FILES/CATALOG/CSI Masterformat - CURRENT.xlsx (renamed from dated filename)
ACTIVE FILES/TD_Production_Open_Workstreams.txt (renamed from dated filename)
ACTIVE FILES/TD_Session_Startup_Cheatsheet.txt (references updated)
ACTIVE FILES/TD_Catalog_Session_Orientation.txt (references updated)
SESSION PROTOCOLS/PARAMETRIC PRICING/TD_Parametric_Pricing_Protocol.txt (references updated)
PROJECTS/KELLER/Keller_parametric_pricing.py (catalog path updated)

All timestamps cluster within a narrow window consistent with a single active session.
Hypothesis:
The model appears to have observed incoming MCP responses confirming its own writes and misattributed them as evidence of a concurrent external session. This may be a reasoning failure specific to how Fable 5 interprets agentic feedback loops under multiple active MCP connections.

KMS_INDEX.txt

[CSI Masterformat - CURRENT.xlsx](https://github.com/user-attachments/files/28895637/CSI.Masterformat.-.CURREN

TD_Catalog_Session_Orientation.txt

TD_Parametric_Pricing_Protocol.txt

Keller_parametric_pricing.py

T.xlsx)

TD_Production_Open_Workstreams.txt

TD_Session_Startup_Cheatsheet.txt

What Should Happen?

The model should correctly attribute filesystem MCP write confirmations as responses to its own operations. It should not interpret successful write acknowledgments as evidence of an external party concurrently editing the same files. The session should persist and remain accessible in chat history after completing its work.

Error Messages/Logs

No error message was displayed before the crash. The session disappeared without warning and no longer appears in chat history.
Claude Desktop application logs may contain relevant entries. On Windows the typical location is:

Steps to Reproduce

chrome-native-host.log

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Sonnet 4.6 (Claude Desktop)

Claude Code Version

N/A - Claude Desktop bug, not Claude Code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This bug occurred in Claude Desktop using the Fable 5 model, not in Claude Code. Reporting here as no Claude Desktop-specific issue tracker was found. The model confabulated external concurrent filesystem writes during its own MCP operations.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗