FilesystemMiddleware can emit an unreadable /conversation_history/<uuid>.md reference after oversized HumanMessage eviction

[AnqiHuangQiQi]

Submission checklist

• This is a bug, not a usage question.
• I added a clear and descriptive title.
• I searched existing issues and didn't find this.
• I can reproduce this with the latest released version.
• I included a minimal reproducible example and steps to reproduce.

Area (Required)

• deepagents (SDK)
• dcode
• talon
• acp
• evals
• daytona
• modal
• quickjs
• runloop
• vercel
• langsmith-sandbox
• Other / not sure / general

Related Issues / PRs

Related issue: #5123
That issue requests exposing FilesystemMiddleware eviction limits through
create_deep_agent(), but it was automatically closed without resolution.

Reproduction Steps / Example Code (Python)

from deepagents import create_deep_agent
from deepagents.backends import StateBackend
from langchain_core.messages import HumanMessage
agent = create_deep_agent(
    model="anthropic:claude-sonnet-4-6",
    backend=lambda runtime: StateBackend(runtime),
    system_prompt=(
        "If the user message is replaced with a /conversation_history path, "
        "immediately call read_file on that path."
    ),
)
prompt = (
    "Review this content. If it is archived, read the archive before answering.\n"
    + ("x" * 210_000)
)
for event in agent.stream(
    {"messages": [HumanMessage(content=prompt)]},
    stream_mode="values",
):
    print(event)

Error Message and Stack Trace (if applicable)

Error: File '/conversation_history/473efc2b-7d37-4fe2-ba65-eadda9f36464.md' not found

Description

The oversized HumanMessage is evicted to a randomly generated
/conversation_history/<uuid>.md path. The model receives that path, but
read_file reports that it does not exist. Re-execution can generate another
UUID and repeat the same sequence.

And this end in a non-stop loop.

Environment / System Info

OS: Linux
deepagents: 0.6.8
langchain: 1.3.10
langchain-core: 1.4.7
Backend: StateBackend
Execution environment: durable/replayed workflow runtime

[teachershuang]

I tried a network-free equivalent on current main (0bacb9fb, deepagents 0.7.19, locked langchain 1.4.2 / langgraph 1.2.11, Windows Python 3.13.5) and have not reproduced the missing archive so far.

I used the current StateBackend() API, create_deep_agent, an InMemorySaver, and a scripted BaseChatModel that calls the real read_file tool on the archive path it receives. A 210,000-character human message was archived; the tool read its sentinel successfully, and a second invocation on the same checkpointed thread could read it again. Both invoke and ainvoke passed. This does not exercise your external durable/replayed runtime or the older backend-factory API, and does not establish that your report is fixed.

Which durable runtime/checkpointer and replay sequence are involved? Could you also check whether it occurs with the current StateBackend() API? That should help separate the older state-write behavior from a remaining replay-specific issue before proposing a patch. No implementation or claim from me yet. Investigation and this message are AI-assisted.

[sharosoo]

On 0.6.8, eviction writes Overwrite(...) in the same super-step as the model turn, dropping the model's read_file tool call. Factory API and StateBackend() behave the same. This was tracked as #4682 and fixed in 0.6.11.

On 0.7.19, normal runs and LangGraph checkpoint replay work as teachershuang noted. The archive path in FilesystemMiddleware._evict_and_truncate_messages and _aevict_and_truncate_messages (L3452, L3478) is f"{prefix}/{uuid.uuid4()}.md". When I re-execute the workflow with recorded model responses, eviction writes a new path while the replayed tool call still looks for the original one:

read_file -> Error: File '/conversation_history/<first-run uuid>.md' not found

Deriving the path from a sha256 content hash fixes this, and live runs and checkpoint replay still pass. Media offload already uses {sha256[:16]}. Repro scripts: https://gist.github.com/sharosoo/eef724d54e08fa26e293818c920f5602

Anqi77 (@AnqiHuangQiQi) does your runtime re-call the LLM on replay, or return recorded model responses like Temporal activity history?

I can open a PR with the content-hash path in sync and async eviction, plus a regression test for memoized replay. Could a maintainer assign this issue to me?

AI-assisted investigation; I ran everything locally.