8000 fix(host): the upgrade agent starts and stops the code sandbox's gateway by adeelahmad · Pull Request #544 · adeelahmad/lense · GitHub
[go: up one dir, main page]

Skip to content

fix(host): the upgrade agent starts and stops the code sandbox's gateway - #544

Merged
adeelahmad merged 1 commit into
mainfrom
claude/project-thread-r960xc-c9-sandbox-host
Oct 18, 2026
Merged

adeelahmad merged 1 commit into
mainfrom
claude/project-thread-r960xc-c9-sandbox-host

Conversation

@adeelahmad
Copy link
Copy Markdown
Owner

Description

Before: Settings → Code sandbox → Run the gateway on this machine wrote the request (action=services profile=sandbox turn=on), but the machine's upgrade agent (packaging/host/lens-upgrade.sh) only knew the monitoring, mcp and browser profiles, so the request was refused and Settings kept saying to run the compose line by hand. The docs called the agent's part "in progress".

After: the agent knows the sandbox profile and starts or stops its three containers (openshell-init, the certificates; openshell-key, the client's key; openshell-gateway), as it does for the MCP runner, the browser and monitoring. A machine whose agent is older still shows the line to run by hand until the agent has updated itself, and the docs say so.

The agent's services_of gets the sandbox case; --profile sandbox up -d on, rm -s -f off, and COMPOSE_PROFILES keeps sandbox across upgrades like the other profiles.

Motivation and Context

Chat-gaps plan, C7 follow-up noted in the deep research and sandbox threads: the web app's switch (merged in #497) had nothing to start the containers on an install with an agent. docs/assistant.md ("The gateway") and docs/updates.md (profiles) now describe what's built.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (make hooks checks it on commit).
  • I added or updated tests: packaging/host/test-services.sh has a case for the sandbox profile on and off (its three containers, COMPOSE_PROFILES with matterbridge,mcp,sandbox).
  • My change requires documentation updates, and I have updated docs/ accordingly.
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md.

Evidence

  • sh -n packaging/host/lens-upgrade.sh and sh packaging/host/test-services.sh: all five cases ok (the new one first).
  • mkdocs build --strict: clean.
  • CI's host-agent and docs jobs run the same on the PR.

Done questions (AGENTS.md)

  • Goal: delivers what the user wanted, merged on green CI. The switch in Settings now starts the gateway on installs with an agent. Merging waits for green CI.
  • Agents: the same services action the web app writes is what set_sandbox_gateway (MCP) and PATCH /api/v1/sandbox/settings use, so agents get it too.
  • Zero setup: no new prerequisite. The agent picks the change up with its next self-update, as it does every release.
  • Fewest clicks and keystrokes: one switch, as before; the compose line by hand goes away where the agent is current.
  • Configurable: n/a, no new setting; the existing switch now works.
  • Light: n/a, the sandbox profile stays off by default; nothing is added to the default install.
  • Private and secure: n/a, no new surface. The agent runs the same compose profile an admin would run by hand; the threat model's host-agent entry already covers the services action.
  • Cost: n/a, no model calls.
  • User decides: the gateway starts only when an admin turns the switch on; defaults unchanged.
  • Upgrades: n/a, no stored data. An older agent refuses the profile as before and Settings says so.
  • Honest: the "in progress" line in docs/assistant.md becomes what's built, with the note about older agents.
  • Tests, docs and generated files updated: test case, docs/assistant.md, docs/updates.md, CHANGELOG.md; no generated files touched.
  • Open standards; dependencies keep Lens MIT: n/a, shell and compose only.
  • Result reported with evidence; "refine later" items written down (below).
  • Reuse: the services_of table and the on/off paths the other profiles use; nothing new.

Refine later

  • The agent could report the profiles it knows (in lens-upgrade.sh's status file) so Settings can say "your agent is older" from facts rather than from the refused request.

Generated by Claude Code

sandbox.py has asked the upgrade agent for the sandbox profile since #495, but the agent only knew mcp, browser and
monitoring, so Settings fell back to the line to run by hand. The profile's three containers (openshell-init,
openshell-key, openshell-gateway) join services_of, with a test, and the docs say which agent knows it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HXPWXcSCQb9hWPr7xkZu7B
@adeelahmad
adeelahmad merged commit e68cfbf into main Oct 18, 2026
17 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-r960xc-c9-sandbox-host branch October 18, 2026 03:10
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.

2 participants

0