Dashboard: connect GitHub via OAuth, choose repositories, and run agents/evals in a sandbox built from the checkout

[TonsOfFun]

Summary

Let a dashboard owner connect their GitHub account with OAuth from Settings, choose which of their repositories are available to the workspace, and start a sandboxed runtime from a checkout of one of those repositories. Agent changes and evaluations can then be tested against the tools the checked-out app's own runtime provides, not only the dashboard's built-in toolbox.

Motivation

Right now the dashboard can only run agents with the tools the engine ships (AgentToolbox) and the MCP catalog. An app that uses activeagent defines its own agents and tools. To test a change to one of those agents, or run an evaluation against it, you need that app's code and runtime. The dashboard assistant says as much: "GitHub auth, repo checkout … are not available in this version."

Scope

1. GitHub OAuth connection (Settings → Integrations)

• A Connect GitHub button starts the OAuth web flow, and the callback stores the connection for the owner (the account or user, per Ownable).
• The access token is encrypted at rest, like provider keys, and never rendered back to the client.
• The operator configures it with ActionAgent.github_client_id / github_client_secret, falling back to GITHUB_CLIENT_ID / GITHUB_CLIENT_SECRET. The UI says so when neither is set.
• The OAuth state is single-use and bound to the session.
• Disconnecting removes the token.

2. Repository selection

• List the repositories the connected account can reach, then pick which ones the workspace may use.
• Store only repositories GitHub actually returned for this token. A client can't add arbitrary names.

3. Checkout sandbox runtime

• A new sandbox type (app_runtime) that takes one of the selected repositories and a ref.
• The engine validates the repository against the selection and hands the backend a checkout spec: repository, ref, clone URL and credentials. The backend is the host-registered Incus, Kubernetes or Cloud Run backend, or the in-memory mock.
• The backend clones the repo, boots the app, and reports the runtime's URL. The session exposes the runtime's MCP endpoint (the checked-out app mounts this engine, so <url>/mcp serves its agents as tools). Runs and evals can then use the checkout's own tools.
• The token never appears in summary / details / API responses.

Out of scope / follow-ups

• Evaluation runner option to resolve tools through a sandbox's runtime MCP endpoint instead of the local toolbox.
• Publishing branches/PRs from a sandbox.
• GitHub App installation tokens (per-repo, short-lived) instead of a user OAuth token.

Related: Claude Code connection issue (filed alongside).