Repository navigation
1.9.0: fix a failed boot with Claude Code, and the sandbox browser on the project page - #584
Merged
Merged
Conversation
When a project's boot fails and the owner's Claude Code is connected, the
engine now starts a Claude Code session in the checkout the failed boot
kept (ProjectBootFix). The session is told which step failed, the boot's
error and the tail of the step's log, scrubbed of the project's secrets
and fenced as data, and is asked for the smallest change that lets the
step succeed. When it changed the checkout the boot resumes from the
failed step on its own, and the paths it changed join the install pull
request's allowlist.
A failed boot prefers Claude Code over the setup assistant and falls back
to it, sharing its automatic attempts and "Start it when a boot fails".
The Project page shows what Claude Code is doing ("Claude Code is fixing
bundle_install…") with its session's transcript, a "Fix the boot with
Claude Code" button, and why Claude Code is not used when it is not.
Only a recorded boot fix runs in a failed sandbox; every other session
still needs a ready one.
Also drops the setup assistant's duplicated Environment tab sentence.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 14, 2026
The sandbox browser could only be started and watched from Settings -> Integrations. A project's page now has a Browser tab with the same panel (start and stop, Watch live, Take over), a Watch live (or Open browser) button beside Sandbox running, and ?tab= deep links that the open tab is kept in. Settings -> Integrations stays where every runtime is managed: a sandbox booted for a project links to its page (to the Browser tab while the browser runs), and the project page links back as Manage runtimes. The sandbox summary names its project, and the project's boot status says which modes its browser can start in. The New Project checklist's Browser sessions item no longer says "not available yet": it says the browser can be started and watched from the project page where the backend runs browsers, and that the project's agent works through the app's tools. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh
Without Claude Code, a failed boot falls back to the setup assistant, and CI resolves a provider for it (ollama needs no key), so the test ran an agent against a provider that wasn't there. The two tests that reach the fallback now see no provider, as project_setup_test's does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh
TonsOfFun
force-pushed
the
feat/claude-code-boot-setup
branch
from
October 14, 2026 20:32
85ae163 to
46add98
Compare
From the live test on a fresh docsage checkout, where the automatic fix worked end to end: - The project page kept showing the failed boot and an idle button until a reload, because nothing was at work yet when it loaded. It now keeps reading a just-failed project for up to a minute while an automatic fix can start (awaitingAutoSetup), then follows the session and the resume. - A boot fix runs headless in acceptEdits, so every command was denied and Claude Code hand-edited Gemfile.lock. A boot fix's session now gets --allowedTools for bundle install/lock/update, gem search/list and git status/diff, plus npm/yarn install when a JS step failed (ProjectBootFix.allowed_tools_for), and its prompt lists them. Other sessions get none. - Transcripts no longer show hook and thinking-token system events, or routine rate_limit_events; a limited or rejected one reads as a line. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh
…m path New project opened on the long Before you start checklist, with the repository picker below it. The picker now comes first, and the checklist follows as one summary line (ready, or what needs action and what blocks), open from the start only when an item blocks creating a project. Create stays disabled while one does. On the :local backend, a dashboard that runs its engine from a path has add_engine write that path into the checkout's Gemfile and lockfile, which are on the install pull request's allowlist. A Bundler file that newly points a gem at a path outside the repository (absolute, ~ or ../) is now refused as local_path_gem, with the fix in the refusal; one the repository already had is left alone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh
TonsOfFun
marked this pull request as ready for review
October 14, 2026 21:09
window.confirm blocks the whole page, and browser automation with it, and cannot ask for the name of what is about to go. A shared dialog (ConfirmDialog, utils/confirm.mjs, useConfirm) now asks instead: an accessible alertdialog with a focus trap, Esc to cancel and focus restored afterwards. Deleting a project, an agent, an evaluation or a scenario catalog asks for its name to be typed first, GitHub-style; the other confirmations are a plain Confirm/Cancel. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release: 1.9.0. No
browser-sidecar/changes; the published@activeagents/browser-sidecar@1.9.0matchesmain. File upload through the live view moved to #588 (1.9.1), because it changes the sidecar.Found while testing 1.9's Claude Code repo sandboxes locally against TonsOfFun/docsage. The boot failed at
bundle_installbecause the Gemfile usespath:gems. Claude Code was connected, but nothing used it.Claude Code fixes a failed boot (
da0d64f2)ActionAgent::ProjectBootFix. It runs only on a failed boot whose checkout was kept, on a backend that can run Claude Code and resume a boot (local and Incus), and only when the owner's Claude Code is connected.CodeSession. Only a recorded boot fix may run in a failed sandbox; every other session still needs a ready one..github/exclusion still apply.POST /api/projects/:id/setup/claude_codestarts a fix by hand.The sandbox browser on the project page (
d6206c4a)?tab=browserand the other tabs deep-link.Fixes from the live test of the integration build (
1390a7c1,09dfc531)The automatic boot fix worked end to end on a fresh docsage checkout. These address what the live test turned up:
Live updates: after a boot fails, the project page keeps reading the project for up to a minute while an automatic fix can start, then follows the session and the resume. Before, it showed an idle button until a reload.
Commands: boot-fix sessions get
--allowedToolsforbundle install/lock/update,gem search/listandgit status/diff, plusnpm/yarn installwhen a JS step failed, and the prompt lists them. Every command used to be denied, and Claude Code hand-edited Gemfile.lock. Other sessions get no allowlist.Quieter transcripts: hook and thinking-token system events, and routine
rate_limit_events, are hidden. A limited or rejected one shows as a line.New project: the repository picker comes first. The Before you start checklist follows as a one-line summary that opens on its own when an item blocks creating a project, and Create stays disabled while one does.
Install PR guard: a Gemfile or lockfile that newly points a gem at a path outside the repository (absolute,
~or../) is refused aslocal_path_gem. The:localbackend'sadd_enginewrites the dashboard's engine path there when the dashboard runs its engine from a path.Tests (
46add98c): the boot-fix tests no longer reach a real provider through the setup-assistant fallback. In CI, ollama resolves without a key.Confirmations in the dashboard's own dialog (
cc71c0e6): everywindow.confirmis replaced by an accessible in-app dialog (ConfirmDialog,useConfirm). Deleting a project, agent, evaluation or scenario catalog requires typing its name first. A test fails ifconfirm(comes back.Tests
local_sandbox_backend_test.rbhas a timing flake that this PR doesn't touch (it passed 4 of 4 reruns).maintoo.Open questions
sandbox_login, signing in needs a ready sandbox, so an automatic fix there falls back to the workspace's API key or doesn't run. Is that acceptable for hosted?claudeargv lives in the activeagents app (IncusSandboxService::ClaudeCode) and doesn't pass the boot-fix allowlist yet.🤖 Generated with Claude Code
https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh