Bug: tailAgentToolRun ReadableStream trips cross-DO I/O in same-isolate facet

[harshil1712]

Versions in production: agents@0.12.1 · partyserver@0.5.5 · compatibility_date = "2026-01-28" · compatibility_flags = ["nodejs_compat"].

TL;DR: #1410 fixed _cf_initAsFacet but left the same cross-DO I/O bug in runAgentTool → tailAgentToolRun. When a parent and child facet share an isolate, the native ReadableStream returned by tailAgentToolRun() triggers "Cannot perform I/O on behalf of a different Durable Object (I/O type: Native)".

Summary

PR #1393 / #1410 fixed the cross-DO DurableObjectId IoContext binding in _cf_initAsFacet. That fix allowed facet bootstrapping to succeed. However, the subsequent step inside runAgentTool — live-streaming tool output via tailAgentToolRun — still creates a native ReadableStream in the child facet and passes it back to the parent. The parent then calls .getReader() and .read() on it, which the runtime rejects when both DOs share the same isolate.

This is a different code path from #1410:

• Bug: _cf_initAsFacet throws "Cannot perform I/O on behalf of a different Durable Object" on first this.name read after the #1393 / 0.11.6 fix #1410: _cf_initAsFacet → this.name → ctx.id.name (fixed)
• This issue: runAgentTool → tailAgentToolRun() → stream.getReader() (still broken)

Exact error

Error: Cannot perform I/O on behalf of a different Durable Object.
I/O objects (such as streams, request/response bodies, and others) created
in the context of one Durable Object cannot be accessed from a different
Durable Object in the same isolate. This is a limitation of Cloudflare
Workers which allows us to improve overall performance.
(I/O type: Native)

Reproduction

Minimal parent that delegates to a Think subclass facet via runAgentTool:

// Parent Agent
class AgentClaw extends Think<Env> {
  async runSubAgent() {
    const result = await this.runAgentTool(SubAgentFacet, {
      input: {
        task: "Write a haiku about clouds",
        system_prompt: "You are a poet."
      }
    });
    return result;
  }
}

// Child facet
class SubAgentFacet extends Think<Env> {
  // default Think.tailAgentToolRun returns a native ReadableStream
}

When runAgentTool executes:

1. subAgent(SubAgentFacet, runId) boots the facet ✅ (since Bug: _cf_initAsFacet throws "Cannot perform I/O on behalf of a different Durable Object" on first this.name read after the #1393 / 0.11.6 fix #1410)
2. adapter.startAgentToolRun() injects the message and starts inference ✅
3. adapter.tailAgentToolRun() is called in the child
4. Child returns a native ReadableStream
5. Parent calls stream.getReader() in _forwardAgentToolStream ❌ → throws

The call path in agents:

https://github.com/cloudflare/agents/blob/main/packages/agents/src/index.ts#L3339-L3341

if (adapter.tailAgentToolRun) {
  const stream = await adapter.tailAgentToolRun(runId, { afterSequence: -1 });
  sequence = await this._forwardAgentToolStream(stream, ...);
}

https://github.com/cloudflare/agents/blob/main/packages/agents/src/index.ts#L3564

const reader = stream.getReader();

Suggested fix

The runAgentTool orchestrator should detect when the stream read fails with a cross-DO I/O error and automatically fall back to getAgentToolChunks — which returns plain serializable objects that don't carry native I/O handles.

Alternatively, Think.tailAgentToolRun could return a wrapper that streams over RPC calls instead of a native ReadableStream, similar to how _cf_initAsFacet was fixed by moving from stub.fetch() to RPC.

Affected versions

• agents@0.12.0
• agents@0.12.1
• @cloudflare/think@0.5.0
• @cloudflare/think@0.5.1

Related

• Bug: _cf_initAsFacet throws "Cannot perform I/O on behalf of a different Durable Object" on first this.name read after the #1393 / 0.11.6 fix #1410 — same error class, different code path (fixed)
• Bug + fix: cross-DO I/O error breaks Facet sub-agents #1329 — the original cross-DO I/O bug that introduced RPC-based facet init

[threepointone]

are you sure this bug exists on 0.12.1? I released that hust an hour ago with this #1443 that shoud've fixed it. can you try with latest versions of all packages?

[threepointone]

I can't reproduce this locally, lemme know if you can make a repro

[harshil1712]

Update — different root cause found

We're on agents@0.12.2 / @cloudflare/think@0.5.3 and were still seeing status=error with no error message. After extensive debugging (adding diagnostic logging, isolating via a minimal test repo), we found the actual culprit was not the tailAgentToolRun stream — it was Think's state management API.

Root cause: SubAgentFacet used initialState / setState / super.state to store per-run config (model, system prompt, etc.) between formatAgentToolInput() and getModel()/getSystemPrompt(). Under the hood, Think implements that state via SQLite (this.ctx.storage.sql). Facets are ephemeral and don't have full DO storage backing, so calling setState inside a facet throws a storage error — which manifests as "Cannot perform I/O on behalf of a different Durable Object (I/O type: Native)" at the runtime level.

Why it was invisible: The error occurs inside Think's fire-and-forget keepAliveWhile callback. Think catches it and writes it to the run's DB record, but as an empty string — so runAgentTool's result has status=error with no error field (the agents SDK only populates error when error_message is non-null).

Fix: Replace setState/super.state with plain instance properties. Since facets live for a single invocation there's no need for persistence:

// ❌ broken — setState writes to SQLite, which facets don't support
initialState = { systemPrompt: "", model: "..." };
override setState(s) { super.setState(s); }
private configureFromInput(input) { this.setState({ ... }); }

// ✅ works — plain instance properties, no storage
private _systemPrompt = "";
private _model = "...";
private configureFromInput(input) {
  this._systemPrompt = input.system_prompt;
  this._model = input.model ?? DEFAULT_MODEL;
}

This might be worth a note in the Think/facet docs — the state API looks like a natural fit for passing data between lifecycle methods, but it's a footgun when used in facets.

[threepointone]

Facets do support sqlite tho, and this is meant to be supported

[harshil1712]

Yes, facets do support SQLite. I apologize, I was trying to let the agent be in-charge and drive this. The analysis doesn't seem correct. I am running into issues, and I'm working on creating a reproducible repo. I'll close this issue, and open a new one with proper details and the repo.