Agents are referencing old instance with outdated harness

[jtvargas]

Describe the bug
Basically i setup my agents with one harness and then i stopped and edit the harness to another one and then restart the agent assuming the changes are going to take in place but on the channels they still reference the old instance with the harness that hit the limit.

Steps to reproduce

1. Go to a channel
2. Talk with an agent with some harness, example Codex
3. Hit the limit on codex
4. Go agents and change the agents harness to use another, like Claude
5. Try to talk with the agent
6. Still referencing the instance with the old harness (codex) and not able to respond

Expected behavior
Be able to change the harness smoothly and keep the conversation

Version and platform
Find your version at the bottom of the Settings sidebar. Write "unknown" if you can't determine it.

• Buzz version: Latest
• OS: MacOS

Logs / additional context
I think the instance is not being updated correctly

[LucasMoskun]

Corroborating this on Buzz Desktop 0.5.6 on macOS with a locally managed agent connected to a self-hosted relay.

Our deterministic reproduction exposed the configuration split:

1. Change Agent defaults from Claude to Codex and restart the agent.
2. The UI/global config records preferred_runtime: codex, but the existing managed-agent record can retain its previous agent_command_override, so the old harness still launches.
3. After explicitly repairing that instance to codex-acp, change Agent defaults back to Claude with model claude-fable-5[1m] and restart.
4. The same instance remains on codex-acp because its per-instance override wins, while the global Claude model still reaches startup. The resulting launch is an incompatible combination: Codex harness plus a Claude model ID.

INITIAL_AGENT_MODE=agent-full-access was present throughout and did not affect runtime selection.

Expected behavior: changing an existing agent harness in the UI should atomically update or clear the effective per-instance runtime override, remove or revalidate incompatible model/provider values, restart the intended harness, and display the effective runtime rather than only the selected default. If Agent defaults intentionally apply only to new or unpinned instances, the UI should say so and expose the existing instance pin.

Related to #5262 because both can leave a managed agent appearing configured/online while its actual unattended harness behavior differs from the UI. The root causes are distinct: #5262 is the dontAsk permission regression; this issue is runtime override/config resolution drift.

[LucasMoskun]

Additional concrete evidence from the same reproduction, sanitized to omit keys and credentials:

// global-agent-config.json
{
  "preferred_runtime": "claude",
  "model": "claude-fable-5[1m]",
  "env_var_names": ["INITIAL_AGENT_MODE"]
}

// relevant managed-agent fields during the mismatch
{
  "agent_command": "codex-acp",
  "agent_command_override": "codex-acp"
}

The startup log then recorded the incompatible effective combination:

2026-08-08T00:56:10Z buzz-acp starting: ... agent_cmd=.../codex-acp ... model=claude-fable-5[1m] permission_mode=dontAsk

The current source makes the split explicit. record_agent_command returns agent_command_override before considering the record runtime, while resolve_effective_agent_env_with_def resolves model/provider independently through resolve_effective_model_provider. There is also an explicit test asserting that a Codex override beats a Claude runtime: record_agent_command_override_beats_runtime.

This narrows the likely fix boundary: the harness-change save path must update or clear the per-instance override, and model/provider resolution should be validated against the resulting effective harness before spawn. The resolver precedence itself appears intentional; the UI/config mutation is leaving contradictory layers behind.