v0.3.0

Adds remote execution across all three harnesses. Each provider can now run its CLI through an AgentHarness.Exec implementation instead of a local port: the provider protocol (streaming, questions, approvals, cancellation) stays in your application's node, and only the CLI process moves. AgentHarness.Exec.Local is the default and reproduces local behavior; an application-provided exec module can place the process in a remote sandbox or behind an SSH channel. One implementation covers all three providers, because the contract is byte-level and protocol-free.

Selection is per session. Pi and Codex take provider_options: %{auth: :inherit, exec: {module, opts}}; Claude selects it through the claude_code adapter option. Remote execution requires auth: :inherit, since the fail-closed :subscription mode verifies local CLI state that says nothing about the environment the exec would run the process in.

A new guide, Writing an Exec implementation, walks through building a sandbox adapter using E2B as the example: exactly-once exit delivery, kill reaching the remote process rather than just the stream, writes queued until the remote pid is known, spec translation, and credential redaction.

Also in this release:

• Credential redaction throughout: SessionConfig inspects safely, and every provider session scrubs its raw state via format_status/1, so crash reports rendered with Erlang ~p formatting cannot leak session env values, API keys, or exec options (which routinely carry sandbox tokens).
• Pi turns settle again on current pi releases, which removed the agent_settled frame the session used as its settle point. Without the fix, every turn hung until the harness timeout regardless of transport.
• codex_sdk 0.19.0, which fixes interrupted app-server streams waiting indefinitely.

No breaking changes. Existing Codex, Claude, and Pi sessions run exactly as before; remote execution is opt-in.

{:agent_harness, "~> 0.3.0"}

v0.2.0

Adds Pi as a third supported harness, alongside Codex CLI and Claude Code.

AgentHarness.Providers.Pi drives pi --mode rpc, pi's JSONL command and event protocol over stdio. Pi is bring-your-own-model, so it authenticates through its own /login providers rather than one vendor account.

Pi is also the smallest of the three: four core tools, no permission system, no MCP. Rather than open a session with those settings quietly dropped, the adapter reports approvals, per_session_mcp, and steer as unsupported, and rejects a session that sets mcp_servers, approval_policy, or sandbox. Questions still work, but only through pi's extension UI dialogs.

The adapter was built against pi 0.83.0 rather than its documentation, and a few things differ from what the docs describe:

• Pi sends no startup frame, so readiness needs a get_state probe.
• agent_settled is the terminal marker, not agent_end.
• The abort acknowledgement arrives after the run has already settled, so cancellation keys off the aborted stop reason on turn_end.
• Missing credentials surface as a rejected prompt rather than a startup failure.

Protocol fixtures captured verbatim from a real pi process are checked in under test/support/fixtures/pi, so the normalizer and session tests assert against what pi actually emits.

Nothing changed for existing Codex or Claude sessions.

{:agent_harness, "~> 0.2.0"}

Full changelog: v0.1.0...v0.2.0