Devin runtime mismatch surfaces as a generic INTERNAL failure on account login and show

[0thernet]

Summary

When the Devin CLI on PATH does not match DEVIN_PIN (3000.10.27), oompa account login <profile> --provider devin fails with only "Oompa could not complete the request safely." and oompa account show <profile> --provider devin --json reports "authentication":{"provider":"devin","signedIn":null} with no recovery block and no reason. The operator has no way to learn that the runtime was refused.

Reproduction

The Devin CLI self-updates: on this machine ~/.local/bin/devin is a symlink to cli/_versions/current, which moved from 3000.10.27 to 3000.10.31 during the day. Then:

1. oompa account add devin-acceptance
2. oompa account show devin-acceptance --provider devin --json → signedIn: null, no recovery.
3. oompa account login devin-acceptance --provider devin in a foreground terminal → oompa: Oompa could not complete the request safely.

Cause chain: PinnedDevinRuntimeManager.readAccount maps RUNTIME_MISMATCH (and PROTOCOL_ERROR, PROTOCOL_LIMIT) to readiness unverified; the service projects that as signedIn: null; devinAccountStatusResponseSchema in src/cli.ts requires a recovery block whenever signedIn is null, so the CLI's login preflight fails schema validation and renders INTERNAL. Pointing PATH at the 3000.10.27 binary makes the same commands report signedIn: false and proceed.

Expected

• account show should distinguish "runtime refused" from "unknown authentication", for example authentication.signedIn: null plus a closed runtime: { status: "mismatch", observed: "3000.10.31", pinned: "3000.10.27" } or an UNAVAILABLE failure with reason: devin_runtime_mismatch and nextCommand: oompa doctor --json, matching how Codex reports codex_runtime_mismatch.
• account login should render that same closed failure instead of INTERNAL.
• oompa doctor --offline should report the Devin runtime status next to Codex and Claude.

Related

The Devin CLI auto-updates in place, so an exact pin will drift on every operator machine within days. Either the pin policy needs a documented repin cadence with the /usage fixture re-captured per version, or the runtime should admit a reviewed set of versions.