Scenario 34: Understand portability limits

Use this when planning a multi-harness rollout, evaluating a plugin repo, or debugging why layer apply / mirror did not reproduce every on-disk artifact...

Frequency: Occasional · Status: Shipped

← Back to scenarios index

Use this when planning a multi-harness rollout, evaluating a plugin repo, or debugging why layer apply / mirror did not reproduce every on-disk artifact from the source repo.

Start with the full reference:

Portability limits

Quick checklist:

# See what HarnessTap can import from a dual-mode repo
harnesstap scan . --dry-run

# Preview what each harness would receive
harnesstap layer apply my-setup --project . --harness claude-code,codex,windsurf,opencode --dry-run

# Check mirror warnings for harness-specific surfaces
harnesstap mirror . --dry-run --format json

# List harness capabilities (use --supported for natively serialized hosts only)
harnesstap harness list --format json

Fully bridgeable: skills, instructions, rules, MCP (stdio/http), static commands (md/toml), agents.

Partially bridgeable: hooks (importable, but ${*_PLUGIN_ROOT} paths need plugin install), Copilot namespaced commands.

Harness-specific (mirror warnings): OpenCode .mjs server plugins, pi extensions, Gemini extension manifests, statusline hooks, runtime session config.

Workarounds: layer plugin pins + resource sync, automatic dual-mode scan, mirror --reference auto|plugin, and native copilot plugin install for Copilot plugin trees.

Related scenarios: 31, 32, 33, 19.