Portability Has a Cost

Everything Claude Code (ECC) makes a strong portability claim, but the useful question is not whether a host is “supported.” It is which workflow assets travel, which enforcement surfaces are adapted, and which capabilities disappear at the boundary. This chapter uses ECC's graded support model and selective installer to help readers choose a proportionate setup and understand what install-state can—and cannot—repair later.

The preceding trust model matters here. A handoff can travel as data while authority remains local. A skill can travel as shared guidance while hooks, permissions, paths, and session events change. Portability is therefore not the absence of differences. It is the discipline of preserving the durable source and naming the differences that a target adapter introduces.

Supported does not mean the same

ECC's compliance matrix uses four states. Native means ECC can install or verify the surface directly for a harness. Adapter-backed means a plugin or translation layer exists, but the host's behavior differs. Instruction-backed means the guidance and files can be supplied, while the harness does not expose all the runtime hooks or session mechanisms needed for enforcement. Reference-only means ECC may learn from or compare with a tool without shipping a direct installer or adapter.

Those categories prevent a common comparison error: treating a shared skill file as evidence of shared runtime behavior. Claude Code is the primary native surface in ECC's documentation, with native plugin assets and hook loading. Codex can consume shared skills and plugin metadata, but its approval and hook semantics are not identical to Claude Code's. OpenCode uses a plugin and event model. Cursor uses project-local assets and an adapter for its event shape. GitHub Copilot receives instruction and prompt files but does not provide ECC's hook system, subagent API, or native skill discovery. A terminal-only workflow lacks the higher-level host surface but remains the portability floor for explicit scripts and documents.

A useful comparison therefore asks four questions. What asset is actually supported? How is it activated? Can it block or only advise? What must the operator verify in the target environment? The answers can differ even for the same named workflow. A security review skill may be available everywhere as text, while a pre-tool secret check may exist only where the harness emits the relevant event. A memory document may be readable in several hosts, while the server identity and user-scope permissions of an optional MCP adapter must be configured separately.

The thin-adapter rule protects the shared source from this variation. Durable behavior should remain in skills, rules, hooks, manifests, session contracts, and memory formats. The adapter should translate loading behavior, event names, command routes, target paths, and platform limits. If the same workflow must be rewritten in three platform directories to keep working, the common behavior probably lives at the wrong layer.

Thin does not mean trivial.