Skip to content

1.9.0: fix a failed boot with Claude Code, and the sandbox browser on the project page - #584

Merged
TonsOfFun merged 7 commits into
mainfrom
feat/claude-code-boot-setup
Oct 15, 2026
Merged

TonsOfFun merged 7 commits into
mainfrom
feat/claude-code-boot-setup

Conversation

@TonsOfFun

@TonsOfFun TonsOfFun commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Release: 1.9.0. No browser-sidecar/ changes; the published @activeagents/browser-sidecar@1.9.0 matches main. 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_install because the Gemfile uses path: gems. Claude Code was connected, but nothing used it.

Claude Code fixes a failed boot (da0d64f2)

  • New 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.
  • The prompt names the failed step and includes the end of that step's log. Project secrets are scrubbed from the log, which is fenced as untrusted data. Claude Code is asked for the smallest change, with no commit, push or server start.
  • It's a normal CodeSession. Only a recorded boot fix may run in a failed sandbox; every other session still needs a ready one.
  • If the session changed files, the boot resumes from the failed step, and the changed paths join the install PR's allowlist. The secret scan and the .github/ exclusion still apply.
  • A failed boot tries Claude Code first, then the setup assistant. Both share "Start it when a boot fails" and the limit of 3 automatic attempts.
  • POST /api/projects/:id/setup/claude_code starts a fix by hand.
  • The Setup card shows a status line, the live transcript and diff, and a "Fix the boot with Claude Code" button.
  • Fixes the duplicated "Environment tab" sentence in the setup assistant's message.

The sandbox browser on the project page (d6206c4a)

  • A Browser tab sits next to Overview, Explorations and Environment ("Browser · live" while it runs), with Start/Stop, Watch live and Take over/Hand back.
  • The header shows Watch live or Open browser, and ?tab=browser and the other tabs deep-link.
  • Settings → Integrations stays the place to manage every runtime. Each sandbox card links to its project, and the project page links back as Manage runtimes.
  • The preflight's "Browser sessions" item describes what the backend supports instead of "Not available yet".

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 --allowedTools for bundle install/lock/update, gem search/list and git status/diff, plus npm/yarn install when 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 as local_path_gem. The :local backend's add_engine writes 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): every window.confirm is 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 if confirm( comes back.

Tests

  • actionagent (Ruby 4.0.6): 1688 runs, 0 failures, 7 skips. local_sandbox_backend_test.rb has a timing flake that this PR doesn't touch (it passed 4 of 4 reruns).
  • frontend: 584 pass.
  • browser-sidecar: 128 pass (unchanged).
  • rubocop: clean.
  • CI also needs 1.9.0: fix CI drift from ruby_llm 2.1.1 and faraday-net_http 3.5.0 #587: ruby_llm 2.1.1 breaks two eval tests on main too.

Open questions

  • With 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?
  • Who should be billed: the project creator for an automatic fix, and whoever clicks for a manual one?
  • Should the paths a fix changed need an explicit opt-in to the install PR?
  • The Incus backend hasn't been tried on a failed, kept container. Its claude argv lives in the activeagents app (IncusSandboxService::ClaudeCode) and doesn't pass the boot-fix allowlist yet.
  • The header's Watch live label refreshes only when the project reloads.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CJAKwnkBaCGr5qjCcmc3kh

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>
@TonsOfFun TonsOfFun changed the title Fix a failed project boot with Claude Code, and upload files through the live view Fix a failed boot with Claude Code; upload files and watch the sandbox browser from the project page Oct 14, 2026
TonsOfFun and others added 2 commits October 14, 2026 13:26
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
TonsOfFun force-pushed the feat/claude-code-boot-setup branch from 85ae163 to 46add98 Compare October 14, 2026 20:32
TonsOfFun and others added 2 commits October 14, 2026 13:35
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 TonsOfFun changed the title Fix a failed boot with Claude Code; upload files and watch the sandbox browser from the project page 1.9.0: fix a failed boot with Claude Code, and the sandbox browser on the project page Oct 14, 2026
@TonsOfFun
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
@TonsOfFun
TonsOfFun merged commit ba7fb3a into main Oct 15, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant