Connect coding-agent execution

Connecting coding-agent execution lets Fullbeam run private baseline-versus-candidate work and prove which Stack Release actually ran. Fullbeam uses isolated, ephemeral managed environments and customer-owned provider credentials. Fullbeam qualifies the release; it does not deploy or enforce the coding-agent setup.

Isolated Fullbeam execution · Ephemeral workspaces · Customer-owned provider credentials

Connect the repositories and provider

Install the Fullbeam GitHub App for the target repositories and the repository that versions the coding-agent stack. Then create a provider credential profile from Qualification.

Fullbeam currently supports managed adapters for Claude Code, Codex, and OpenCode, with customer-owned Anthropic, OpenAI, or OpenRouter credentials where the selected harness supports them. Attempts run in Daytona's EU target and provider calls pass through the Fullbeam model gateway so per-attempt authorization, usage settlement, and credential isolation can be enforced. The sandbox receives a short-lived gateway token; the provider credential remains behind the gateway. No customer runner installation is required.

Confirm it is working

Before launching a qualification, check that:

• the target repository and Stack Repository are connected through the GitHub App;
• the Golden Set cases are frozen and eligible;
• both Stack Releases resolve to exact commits and supported adapter versions;
• the selected provider credential profile is valid.

Launch a small qualification and confirm that Fullbeam records the declared, materialized, and observed runtime identity, hidden verification outcome, usage and cost coverage, cleanup receipt, and result identity. Missing runtime observations remain explicit.

Production admission also requires Fullbeam operators to retain a passing live Daytona regional, network, opaque-secret, and cleanup canary for the deployed release. A configured API key or stored digest alone is not proof that the external environment enforces the boundary.

The assigned Stack Release and effective runtime are separate facts. A declared candidate is not considered verified merely because a job was scheduled for it.

Keep credentials private

Never paste a provider credential into a repository, Stack Release, issue, pull request, chat, or support message. Store it only through the provider credential form. If it may have been exposed, revoke the profile and rotate the credential at the provider.

Next: Qualify a Stack Release.