Config-driven runtime selection doesn't validate against ValidRuntimes() before sandbox bootstrap

[waynesun09]

Summary

internal/cli/run.go's resolveBackendFromConfigData() calls config.ParsePerRepoConfig/config.ParseOrgConfig (pure YAML unmarshal, no .Validate() call) and passes the result straight into agentruntime.ResolveFromConfig/ResolveFromPerRepoConfig → Resolve(), which switches on the runtime name with no check against config.ValidRuntimes().

This means runtime: opencode or runtime: pi in org/per-repo config resolves successfully (both are registered in Resolve()'s switch for dev/testing purposes) even though neither is in ValidRuntimes() and both are non-functional stubs. A config author who sets one of these runtimes will have the run proceed through sandbox creation, fetch-service setup, and bootstrap/env wiring before failing inside rt.Bootstrap() — burning real (if bounded) side effects before the failure surfaces, rather than failing fast at config-parse time.

Scope

This affects both stub runtimes identically:

• opencode (added in refactor(runtime): register opencode as a stub runtime #6035)
• pi (added in refactor(runtime): register pi as a stub runtime #6466)

Confirmed via git history that this is not specific to either PR — the gap has existed since opencode's registration and pi simply inherited it.

Suggested fix

Add a ValidRuntimes() guard directly inside agentruntime.Resolve() (or call .Validate() in resolveBackendFromConfigData before resolving), so config-driven runtime selection — org or per-repo — fails immediately, before any sandbox is created, for any runtime not in ValidRuntimes(). Keep runtime.Resolve("pi")/Resolve("opencode") working for explicit dev/testing call sites that don't go through config.

Update the tests in internal/runtime/registry_test.go that currently assert opencode/pi resolve successfully via ResolveFromPerRepoConfig — once the guard lands, that codepath should return an error instead.

References

Originally raised by an automated review bot on #6466 (review thread), confirmed and scoped via independent review-squad analysis (Claude + Grok) which traced the actual fullsend run side-effect ordering to establish this is bounded to sandbox/bootstrap overhead (no wasted inference calls, since Bootstrap() fails before Run() is ever reached).

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 12:25 AM UTC · Completed 12:29 AM UTC

Commit: 6fa6cb9 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: Medium — bounded side effects (sandbox/bootstrap overhead), no wasted inference.

Root cause: resolveBackendFromConfigData() skips Validate() and Resolve() has no ValidRuntimes() gate, so stub runtimes pass through the config path unchecked.

Recommended fix: Add a ValidRuntimes() guard on the config-driven resolution path (either in Resolve() with a config-path flag, or in resolveBackendFromConfigData before calling Resolve). Keep direct Resolve("pi")/Resolve("opencode") working for dev/testing.

Proposed test:

func TestResolveFromPerRepoConfig_RejectsStubRuntimes(t *testing.T) {
    for _, name := range []string{"opencode", "pi"} {
        cfg := &config.PerRepoConfig{Runtime: name}
        _, err := agentruntime.ResolveFromPerRepoConfig(cfg)
        require.Error(t, err, "stub runtime %q should fail via config path", name)
    }
    // Direct Resolve() still works for dev/testing
    for _, name := range []string{"opencode", "pi"} {
        rt, err := agentruntime.Resolve(name)
        require.NoError(t, err)
        assert.NotNil(t, rt)
    }
}

Related: #6464 (pi runtime tracker), PR #6466 (pi stub registration, open), PR #6035 (opencode stub, merged).

---

Labels: Bug in runtime config validation path affecting runner and harness components, bounded impact warrants medium priority.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 12:31 AM UTC · Completed 12:40 AM UTC

Commit: 6fa6cb9 · View workflow run →