Schema: idiomatic way to encode against a type-erased `Schema.Top` (codec services show as `unknown` in the requirements channel)?

[schickling-assistant]

This is a usage/idiom question about encoding against type-erased schemas.

When you only have a type-erased Schema.Top — e.g. from RPC dynamic dispatch, heterogeneous registries, or plugin systems where the concrete schema type is lost — encoding a value against it as JSON surfaces unknown in the requirements (R) channel:

declare const erased: Schema.Top
const eff = Schema.encodeUnknownEffect(Schema.toCodecJson(erased))(value)
//    eff: Effect<Json, SchemaError, unknown>   // <- unknown in R

Schema.Top types DecodingServices/EncodingServices as unknown, and toCodecJson + encodeUnknownEffect forward them into R. @effect/language-service flags it as anyUnknownInErrorContext (TS377030, "unknown in the requirements channel"). But such schemas are plain data — they need no codec services (the repro verifies this at runtime).

The only clean fix we found is an unsafe cast asserting the (true) never service channels:

Schema.toCodecJson(erased as Schema.Codec<unknown, unknown, never, never>)
//    -> Effect<Json, SchemaError, never>

We confirmed encodeUnknownExit / encodeUnknownResult (which return Exit/Result with no R channel) don't avoid the cast — their ConstraintEncoder<unknown> bound requires EncodingServices extends never, which Schema.Top doesn't satisfy.

Question: is casting the service channels the idiomatic way to encode/decode against a Schema.Top known to need no services, or is there a cleaner, more Effect-native API for this (a service-erasing combinator, an encode variant that ignores services, a better way to type-erase RPC schemas, etc.)?

Reproduction

https://github.com/schickling-repros/2026-07-effect-erased-schema-services

bun install
bun run repro   # tsc type-assertions (R=unknown vs R=never) + a runtime check

Versions

• effect: 4.0.0-beta.98
• @effect/language-service: anyUnknownInErrorContext (TS377030)

Context: this arises encoding RPC exit/payload schemas after dynamic dispatch erases them to Schema.Top — a follow-on to #6064 (which exposed successSchema but not the service-typing question).

Posted on behalf of @schickling

field	value
agent_name	🌲 cl1-pine
agent_session_id	b9f1f4a5-dd10-40f6-b25c-945e71e2007a
agent_tool	Claude Code
agent_tool_version	2.1.206
agent_runtime	Claude Code 2.1.206
agent_model	claude-opus-4-8
runtime_profile	/nix/store/1n76sy6i9y3ki3k4w04jksqvygw67sj0-coding-agent-runtime-profile/share/coding-agents/profile.json
skills_manifest	/nix/store/jn6r0r7r59x3a525jch4pwzwykszqp60-agent-skills-corpus/share/agent-skills/manifest.json
worktree	livestore/schickling/2026-07-17-refactor
machine	dev3
tooling_profile	dotfiles@4eac376

[schickling-assistant]

Follow-up from the same setting (a custom Cloudflare Durable-Object RPC server that dispatches handlers fetched from a runtime map, context.mapUnsafe.get(rpc.key)). We hit two related instances of the same dynamic-dispatch erasure, and I want to check whether our workarounds are the intended pattern or whether there's a more idiomatic API.

1. Encoding erased exit/payload schemas (the original topic here).
Rpc.exitSchema(rpc) as Schema.Top erases the schema; Schema.encodeUnknownEffect(Schema.toCodecJson(top)) then carries unknown in the requirements channel (anyUnknownInErrorContext / TS377030). Our workaround is to assert the true never services in one place:

const erasedJsonCodec = (schema: Schema.Top) =>
  Schema.toCodecJson(schema as Schema.Codec<unknown, unknown, never, never>)

(We verified encodeUnknownExit/Result don't help — their ConstraintEncoder<unknown> bound requires EncodingServices extends never, which Schema.Top doesn't satisfy.)

2. Running the dispatched handler.
entry.handler(payload, …) is typed Effect<any, any> (concrete A/E/R are erased by dynamic dispatch). yield*-ing it trips anyUnknownInErrorContext on the any error channel. We tried to clear this idiomatically rather than suppress — capturing the outcome with Effect.exit (which collapses the error channel to never):

const rawExit = Effect.isEffect(x) ? yield* Effect.exit(x) : Exit.succeed(x)

but verified across five variants (Effect.exit alone; + a cast to Effect<unknown, unknown, Rpc.ToHandler<Rpcs> | Rpc.Middleware<Rpcs>>; + R = never; + a typed intermediate const; + a return-typed helper) that the rule still fires — because the erased handler's error must be written as unknown/any in some position the rule checks, and the only clearing form is a dishonest E = never cast (the handler can genuinely fail). So we keep a :off there, and Effect.exit only buys a code simplification (it removes a parallel catchCause), not suppression removal.

Questions:

• For a custom RPC server that dispatches handlers from a runtime map and re-encodes their exits against Rpc.exitSchema(...), is asserting the erased service/error channels (as above) the intended pattern — or is there a typed API (or a recommended "run this handler and encode its exit" primitive) that preserves the concrete types and avoids the erasure entirely?
• Independently: would it be reasonable for anyUnknownInErrorContext to exempt an unknown/any error that is immediately consumed by Effect.exit / Effect.matchCause (i.e. where the error provably does not escape)? That would let the dynamic-dispatch case be handled idiomatically without a suppression.

Happy to file the second point separately against @effect/language-service if you'd prefer it there.

Posted on behalf of @schickling

field	value
agent_name	🌲 cl1-pine
agent_session_id	b9f1f4a5-dd10-40f6-b25c-945e71e2007a
agent_tool	Claude Code
agent_tool_version	2.1.206
agent_runtime	Claude Code 2.1.206
agent_model	claude-opus-4-8
runtime_profile	/nix/store/1n76sy6i9y3ki3k4w04jksqvygw67sj0-coding-agent-runtime-profile/share/coding-agents/profile.json
skills_manifest	/nix/store/jn6r0r7r59x3a525jch4pwzwykszqp60-agent-skills-corpus/share/agent-skills/manifest.json
worktree	livestore/schickling/2026-07-17-refactor
machine	dev3
tooling_profile	dotfiles@4eac376