feat(isolation): task capsules, isolated worktrees and container runs

[BIackFIame]

Goal

Let an agent work on an isolated copy of the project, in a container if configured, without touching the user's checkout until its output is reviewed.

Behavior

• Task capsules and sandbox plans reject protected mounts and retain hidden edits.
• One live launch policy covers create, restart and restore. It enforces account host affinity, budgets and privacy before every spawn and rechecks after asynchronous waits.
• Host probes are bounded (at most eight concurrent, short caches that coalesce identical reads) and honour account placement.
• Accounts launch their bound model with isolated API credentials. Kimi homes and OpenCode API protocols are aligned.
• Durable isolated git worktrees preserve agent output. Closing the app never removes them, and cleanup removes only unchanged worktrees.
• Containers (Docker and Podman) run with durable owned workspaces. A fixed Python bootstrap checks no-new-privileges, zero capabilities, cgroup limits and mounts before exec. Cleanup is fenced against a pending create.
• A responsive API profile editor, and launcher controls for workspaces and containers.

Verification

• npm run typecheck passed. Full suite: 1044/1044; Even G2 companion tests (npm run test:even): 47/47.
• Live, on the final state of this series: Docker Desktop inventory on macOS, and a Podman shell container on an Ubuntu server with /workspace mounted and no network. The container was removed on exit and the workspace was retained.

Series

Each part is one commit on top of the previous one. Please merge them in order. Until #65 is merged, GitHub also shows the earlier parts here; review only the top commit 942166f (Commits tab → last commit).

Part	PR	Scope	Lines
1	#63	Providers: Cursor, MiniMax Code, Devin, Antigravity	+579/−90
2	#64	API keys, API profiles, agent delegation (MCP)	+4275/−63
3	#65	Remote servers, placement, privacy tiers, accounts	+6620/−40
4	#66	Isolation: capsules, worktrees, containers	+5508/−839
5	#67	ACP, connection settings, remote containers	+6827/−563
6	#68	Project context and learning	+6148/−370
7	#69	Routing, reasoning effort, server preparation, sign-in	+3122/−467
8	#70	Open issues and safe fixes from open PRs	+306/−58

Compatibility with open upstream PRs

integration/stack-with-open-prs is this whole stack with #54–#62 merged on top and every conflict resolved. On that branch both TypeScript checks, 1492/1492 tests, npm run test:even (47/47) and electron-vite build pass.

• fix(even-g2): isolate transport keys per paired device #54, fix(even-g2): align local-network Settings card layout #56, fix(canvas): honor region bounds when snapping resize #57, fix(canvas): let sticky note editors scroll their own text #59, fix(plugins): prevent stale version writes during updates #60 merge cleanly.
• fix(settings): keep rejected writes out of live settings #58: conflicts in SettingsStore.ts. Keep this stack's store: it already serializes every write and publishes a value only after the disk write succeeds. fix(settings): keep rejected writes out of live settings #58's new tests pass against it unchanged.
• fix(window): restore state events after macOS Dock reopen #61: mechanical. registerIpc returns the window observer; keep both sides. This stack's IPC tests stub both window-state helpers, so they pass in either merge order.
• fix(even-g2): require explicit grant for answer capture #55:
  • TerminalManager.ts: keep this stack's launch structure. The answer-capture grant must also reach the prepared and measured-grid first start, because every real agent launch goes through that path.
  • hook-helper.mjs: keep this stack's 512 KiB input read and safe cut, and gate the answer on fix(even-g2): require explicit grant for answer capture #55's grant.
  • Fix and tests: 64ef294 (grant through prepared starts, feat(updates): add GitHub release updates across platforms #62 follow-ups) and c2dd726 (hook test under the grant).
• feat(updates): add GitHub release updates across platforms #62: whichever of this stack and feat(updates): add GitHub release updates across platforms #62 lands second needs the same commit:
  • The restore step in shutdownForUpdate must clear shuttingDown. Otherwise no session can start after a failed update; feat(updates): add GitHub release updates across platforms #62's own test fails without this.
  • Restore only live sessions, using the orphan-subagent rule.
  • Refuse to install while a server is being prepared or a capsule test runs.
  • Open About through SettingsLocation.

I will rebase this stack onto whichever of these lands first.

🤖 Generated with Claude Code

[howdeploy]

@BIackFIame @teo-nex, хочу уточнить направление доработки этого PR.

Сначала нужно переработать сохранение и восстановление сессий агентов, отталкиваясь от основной пользовательской функции: «Сохранять сессии агентов или нет». Вместе с этим следует спроектировать управление контейнерами и связанными рабочими окружениями как расширение этой функции. Пользователю нужна согласованная модель: что сохраняется после завершения работы, что восстанавливается при следующем запуске и как этим управлять.

Пожалуйста, совместно пересмотрите реализацию #66 с этой точки зрения. В фундаменте CanvasTTY должна остаться простая модель жизненного цикла и восстановления сессии; расширенное управление контейнерами и изолированными окружениями должно подключаться опционально через плагины, используя эту модель. Не хочу, чтобы рядом с основной настройкой сохранения сессий возникала ещё одна самостоятельная система управления со своей логикой восстановления.

Общее продуктовое направление касается всей связанной цепочки:

• feat(hosts): remote computers over SSH, placement, privacy tiers and accounts #65 — SSH-компьютеры, размещение агентов, аккаунты и политики;
• feat(isolation): task capsules, isolated worktrees and container runs #66 — изолированные рабочие копии и контейнеры;
• feat(acp): ACP agents, connection settings and remote containers #67 — ACP, подключения, капсулы и управление результатами;
• feat(context): scoped project context, convention imports and learning #68 — контекст проекта, правила и обучение;
• feat(routing): launch routing, reasoning effort, server preparation and sign-in #69 — маршрутизация, reasoning effort, подготовка серверов и вход в аккаунты;
• fix: close open issues and fold in safe fixes from open PRs #70 — финальные исправления и интеграция цепочки; уже перенесённые базовые исправления нужно учитывать отдельно от новых подсистем управления.

Кейсы с отдельной настройкой SSH для меня либо слишком ситуативны, либо ведут к сложным цепочкам оркестрации и управления агентами. Я сам как автор не использую их активно в повседневной работе. CanvasTTY я задумывал как максимально свободную и гибкую платформу, сохраняя минимализм в фундаменте.

Я уже принял много наработок по базовой оркестрации, но дальнейшее развитие этих идей хочу вести именно через систему плагинов — для этого она и создавалась. Сообщество уже сделало удобный поиск, установку и обновление плагинов; давайте использовать этот путь, чтобы каждый пользователь подключал нужную ему сложность самостоятельно.

В #67 оставлю отдельный комментарий о необходимых изменениях ядра плагинов. #62 с обновлением самого приложения ведём отдельно: используем electron-updater и планируем Developer ID для macOS; отдельный Sparkle при этом не нужен.

[BIackFIame]

@howdeploy в работе переработка этих PR, баги- проблемы некоторые нашел + поверх добавление jev и аналогичных моделей.

Оркестрация — отдельные сервера и тп я думал использовать(из личного опыта) для ситуаций когда основной пк/ноутбук банально не справляется/греетчя максимально и нужно больше мощности, и что бы агенты сами все распределяли по доступности и возможностям сервера

[howdeploy]

@BIackFIame, понимаю сценарий с разгрузкой основного ПК и использованием более мощных серверов. Но в целом агент, у которого есть доступ к shell и настроены SSH-доступы, уже может подключаться к серверу и выполнять там задачи.

Поэтому мне кажется, что описание доступных серверов, правила выбора машины и распределение работы — прежде всего вопрос пользовательских скиллов, хуков и настроек самого агента. Для этого не обязательно делать управление SSH и серверами частью архитектуры ядра CanvasTTY.

Если хочется оформить этот сценарий в удобный интерфейс с автоматизацией, я вижу ему место в опциональном плагине. Со стороны CanvasTTY стоит определить минимальные точки расширения, которых для этого действительно не хватает. Это позволит реализовать твой сценарий и сохранить простой фундамент для пользователей, которым такое управление не нужно.

[BIackFIame]

Заменено: функции вынесены в плагины canvastty-plugin-* (environments, assistant, accounts, context, acp), точки расширения ядра — в #81–#88. Подробно — в комментарии в #67: #67 (comment)