Scenario 17: Migrate HarnessTap state to a new machine
Use this when moving setups across laptops or onto a dev box. For a single archive that includes harness preferences and config, prefer Scenario 28.
Frequency: Rare · Status: Shipped (manual workflow — see Scenario 28 for one-command migration)
Use this when moving setups across laptops or onto a dev box. For a single archive that includes harness preferences and config, prefer Scenario 28.
Manual workflow with current commands:
# On the old machine
mkdir -p ./bundles
for p in $(harnesstap layer list --format json | jq -r '.[].name'); do
harnesstap migrate export "./bundles/$p.harnesstap.toml" --layer "$p" --embed-plugins
done
# Copy ./bundles/ to the new machine, then:
harnesstap init
for f in ./bundles/*.harnesstap.toml; do
harnesstap migrate import "$f"
done
harnesstap harness set --main claude-code --aliases cursor,codex # restore selection--embed-plugins is recommended for portability so the new machine does not
need to re-fetch marketplace plugin trees. This workflow does not currently
carry over harness preferences or ~/.harnesstap/config.json; copy those by
hand or use Scenario 28.
Scenario 16: Enforce layer and plugin state in CI
Use this when you want CI to fail if the project drifts away from its layer or its pinned plugin versions.
Scenario 18: Debug committed vs effective Claude plugin settings
Use this when the plugin set declared in the project's .claude/settings.json differs from what Claude Code actually loads after merging user, project, and...