Switch harness mid-feature

You need a hall with at least two providers and a feature with a session. This example moves avatar-url to OpenCode. If the hall lacks the provider, ivar provider add opencode registers it.

ivar session relay avatar-url --provider opencode

--provider is required, because a relay exists to switch harnesses.

What happens

• The worktrees are git, the manifest is JSON and the skills are folders of Markdown, so nothing in the view dir belongs to one vendor.
• The feature keeps its branch and its promoted repos. Only the harness that reads them changes.
• The new session gets the new provider's native files: .opencode/ and AGENTS.md in this example.
• Nothing is uploaded to do it.
• To open a fresh session on the same feature under the new provider, use ivar session start avatar-url --provider opencode.

Use it when one harness hits a limit you do not want to wait out, or when a teammate prefers another one. Check the result with ivar feature status avatar-url: the promoted repos and their states match what you left. Run ivar session stop on the old session when you finish with it, so a second agent never writes into the same worktrees.

The relay prints four lines of output for external consumers, so a script or an editor can read the new session's binding. Add --json for the same value in machine-readable form. The hall's ivar.json lists which providers are available, and ivar provider list shows them with the default.

Instruction files follow the provider. The hall's HALL.md becomes CLAUDE.md for Claude Code and AGENTS.md for OpenCode and OMP, so the new agent starts with the same rules the old one had, and the skills are the same Markdown folders under a different harness directory.

Read the full walkthrough

The session reference covers relay and the binding variables a session exposes. With OpenCode, with Claude Code and with OMP show what each harness gets.