test(sdk): transport tests fail on main at the sessions.get error assertion — sessions.get error does not match {_tag: SessionNotFoundError} in the test flow (unit linux red) #62

Summary

packages/sdk/test/transport.test.ts fails on main — both variants (create and layer) — at the sessions.get error assertion (line 53). This is currently the only failure in the @opencode/sdk package and it keeps unit (linux) red on main.

Evidence

CI: run 39139947287 (main 94276dae0, 2026-10-18) — unit (linux) job: @opencode/sdk reports 37 pass / 2 fail, and the only two failures are:

• create keeps requests and streams on its own transport despite an ambient Fetch
• layer keeps requests and streams on its own transport despite an ambient Fetch

Both fail at packages/sdk/test/transport.test.ts:53:

expect(yield* client.sessions.get({ sessionID: missing }).pipe(Effect.flip)).toMatchObject({
  _tag: "SessionNotFoundError",
})
error: expect(received).toMatchObject(expected)
+ [SessionNotFoundError: Session not found: ses_...]

Reproduced locally on unmodified main (94276dae0): bun test test/transport.test.ts from packages/sdk → 0 pass / 2 fail, same location, deterministic across runs (including a verbatim copy of the file under a different name).

What is already known (please read before "fixing" the obvious theory)

• The sessions.export assertion for the same missing session (line 50, same expected _tag) passes in the same test. Only the direct sessions.get path (served by core without HTTP, per the comment at line 49) fails.
• packages/sdk/src/effect/opencode.ts:62-63 already maps the core error: host.sessions.get(...).pipe(Effect.catchTag("Session.NotFoundError", missingSession)), and missingSession (packages/server/src/handlers/session-error.ts:6) builds a protocol SessionNotFoundError.
• Probing the flipped sessions.get error in isolation shows it is correct on every inspectable axis: _tag === "SessionNotFoundError" (own, enumerable), instanceof the protocol SessionNotFoundError, sessionID matches, and the same toMatchObject({ _tag: "SessionNotFoundError" }) assertion passes on the probed value in a standalone test file. So "the SDK returns the core Session.NotFoundError tag" is disproven — do not just re-check the tag mapping.
• Bun's failure diff is misleading here: it renders the expected _tag as "Session.NotFoundError" (with a dot) even though the test file says "SessionNotFoundError". Trust direct probes (_tag, descriptors, instanceof) over the diff rendering.

So something about the error object as produced inside this test's full flow (embedded host creation with an ambient FetchHttpClient.Fetch provided, after create/log/subscribe calls) makes Bun's toMatchObject reject it, while the same-shaped object passes in isolation. Candidates to investigate: a second copy/instance of the protocol errors module in the embedded-host module graph (dual-package identity), an extra non-enumerable state on the error that toMatchObject trips on in this context, or the assertion style itself being the wrong tool for a Schema.TaggedError here (compare packages/client/test/effect.test.ts:375, which asserts error._tag directly and passes, and packages/server/test/handler-policy.test.ts, which asserts toMatchObject({ sessionID, message }) + toBeInstanceOf and passes).

Why it matters

• unit (linux) is red on main, which trains everyone to ignore the job — the same masking that hid the failures fixed in lint(core): unit (linux) fails effect-simplifications — two Effect.catch(() => Effect.succeed(...)) sites should be Effect.orElseSucceed #52/test(schema): two tests fail on Windows — file URL .pathname gives '/D:/...' ENOENT; use fileURLToPath #53.
• If the cause is module-identity duplication in the embedded SDK graph, it can bite real consumers too (e.g. instanceof/tag checks on SDK errors), not just this test.

Acceptance criteria

• Root cause identified and recorded on this issue (not just the assertion relaxed to make it green).
• bun test test/transport.test.ts in packages/sdk passes (both variants), locally and in CI.
• unit (linux) on main goes green for the @opencode/sdk package.
• If the fix is test-only, explain why the production error path was already correct; if it is a product fix, add/keep a regression assertion that would catch the real consumer-facing symptom.