feat(core): consolidate session restore, plugin extensions and agent safety

[BIackFIame]

Purpose and scope

This is the consolidated PR for the session, plugin and agent-safety work originally submitted as #81–88. It provides one place to finish the implementation and review the complete integration against main.

The intended features remain in scope. The PR stays Draft while the correctness and integration findings in the maintainer review are addressed. Please push follow-up fixes to this PR's existing branch, core/7-auto-profile, and link each fix and its regression coverage in your reply to the review.

Included changes

Original PR	Included behavior
#81	Authenticate the orchestration helper with the connection ID issued by the host. This fix and its tests are incorporated in the later stack.
#82	One persisted session model for reopening and resuming cards, including conversation identity and stopped sessions.
#83	Plugin service processes behind separate native-code trust, with host RPC and service lifecycle management.
#84	Plugin contributions to agent launches: selected options, environment variables, secrets and per-run files.
#85	Plugin-provided session environments with prepare, wrap, resume, describe and release operations.
#86	Base protection, plugin decision hooks, launch policies and secret redaction.
#87	Plugin tools for agents, session events and control, card actions and badges, and dynamic launch choices.
#88	Auto launch profiles, third-party-model downgrade, per-run Codex trust and Claude lifecycle handling.

The branch already contains the #82–87 commits; no cherry-picking or history rewriting is needed to consolidate their review. The #81 authentication implementation and regression tests are included through #87. The superseded PR branches and commit history are retained.

The branch also contains the exact Codex restore fix from #80 by @teo-nex. That PR remains a separately tracked dependency; the consolidation does not change its authorship or merge it independently.

Auto profile behavior

• Normal remains the default, including for spawn_agent children.
• Auto is offered for Codex (--approve-for-me), Claude Code (--permission-mode auto with sandbox settings), and Grok (--permission-mode auto).
• A launch contribution marked thirdPartyModel: true downgrades Auto to the provider's accept-edits behavior. Codex and Claude retain the configured sandbox; Grok has no sandbox or decision-hook guarantee here.
• Codex receives per-run trust for CanvasTTY's own hooks and for subagent folders within the user's selected local project. The implementation does not write these trust settings to the user's persistent Codex configuration.

Validation status

At reviewed head 1f38707009962f5fb4132e4690dfe5e6609cade8, GitHub reports successful verify, windows-pipe-host and macos-cli-resolution checks.

The original author reported 993/993 suite checks, typecheck, electron-vite build, the secret audit, and 47/47 test:even checks, plus live checks with Claude 2.1.281, Codex 0.156.1 and a local model under a temporary HOME. These are the author's reported results, not additional runs by the maintainer reviewer.

The maintainer review is static: code paths, existing tests and documentation were inspected; no local tests, build or live application checks were run. The review identifies missing regression scenarios despite the existing green CI.

After the review was posted, the author refreshed the stack to e2de0d87cd95751604f26ceb00cb1e8033f8908e. The maintainer inspected that delta: review item 8 (stale conversation identity after Reopen) is addressed in code with added regression cases; items 1–7 remain open. The CI results above belong to the earlier reviewed head and are not a claim about this updated head.

Completion before merge

Address each numbered item in the maintainer review, preserve the intended features, add focused regression coverage, and report validation against the final corrected head. Once that evidence is available, this single PR can be reviewed for merging into main.

[howdeploy]

@BIackFIame — the direction of this work matches what we want for CanvasTTY. Please keep the features and finish the integration here. We are consolidating #81–88 into this PR so there is one implementation branch, one discussion and one set of merge criteria.

Review outcome: changes requested before merging into main. The findings below are about concrete code paths in the combined implementation, not a request to replace the design or remove the new functionality.

Reviewed head: 1f38707009962f5fb4132e4690dfe5e6609cade8. This was a static review of the implementation, its callers, existing tests and documentation. I did not run local tests, the build, or live CLI/UI checks. The reproduction and verification cases below are scenarios to cover, not claims that I executed them. The three GitHub CI checks were green at this head.

Update after the concurrent stack refresh: I inspected the delta to e2de0d87cd95751604f26ceb00cb1e8033f8908e. Item 8 is addressed at the code-review level: the restore plan now carries the selected conversation identity, fresh launches discard the previous ID, and regression cases were added for Reopen and held cards. I have not run those tests. Items 1–7 remain open; their implementation paths were not changed by this update. The refreshed #82–87 heads are all ancestors of the refreshed #88 head, so their changes are retained in this consolidated PR.

1. P1 — Preserve a pending environment choice across shutdown and restore

Code: TerminalManager.create, environment preparation, persisted session serialization.

create() stores environmentChoice only on the in-memory session. It immediately persists the card with exitCode: null, so the saved state is running. However, extras.environment is not assigned until environment.prepare resolves, and the serializer does not preserve the pending choice.

If the app exits or crashes while preparation is pending, the saved record looks like an ordinary local session. On the next start it can launch locally in the original directory. This violates the documented guarantee that a selected environment never silently falls back to this computer. A failed prepare also loses its original selection after saving and restoring the failed card, so a later Restart can take the local path.

Required behavior: persist enough information to distinguish a pending or failed environment launch from a local session. After restore, either safely recover the selected environment or hold the card stopped with an explanation. Do not infer “local” from a missing prepared ref. Keep the chosen options available for retry, and make the lifetime of any late prepare result explicit.

Regression coverage: defer prepare, create a card, save/shut down before it resolves, then restore from that record and assert that no local PTY is spawned. Cover a preparation failure followed by app restart and manual Restart as well. The existing environment shutdown test waits for all three launches to finish; its pending-prepare case closes the card rather than shutting down and restoring it.

2. P1 — Deliver the initial subagent prompt only after the asynchronous launch is ready

Code: AgentControlService.spawn/send, asynchronous creation, inputChecked.

spawn() calls TerminalManager.create() and immediately calls send() for initialPrompt. With launch options or an applicable launch policy, create() returns a card whose process is still null. send() accepts it because exitCode is still null; inputChecked() then returns false, and input() discards that result. The orchestration caller receives success while the child eventually opens without its task.

This is an integration regression caused by making launch asynchronous without updating the prompt-delivery contract. It also affects send_to_agent while preparation is pending. A policy can trigger it even when the caller did not explicitly select plugin options.

Required behavior: give callers a reliable launch/delivery contract. Await readiness or retain the pending initial prompt and deliver it exactly once when the process is ready. A refused, cancelled or superseded launch must not be reported as successful delivery, and queued input must not reach a later unrelated restart. Apply the fix at the shared boundary used by these callers.

Regression coverage: call the real orchestration/control path with both prompt and launchOptions, hold preparation pending, then resolve it and check the PTY receives the prompt exactly once. Cover policy-only preparation, refusal, and cancellation before readiness. The existing spawn_agent launch-options test uses a synchronous stub and does not supply a prompt.

3. P1 — Validate and merge every supported Claude settings argument form

Code: launch argument validation, mergeClaudeInlineSettings, coreOwnedLaunchArgument.

Validation considers each argv element separately. It parses protected Claude settings only when the element itself starts with {. The merger recognizes only the two-element form --settings, followed by inline JSON. File paths are deliberately left alone.

Consequently, contributions such as the following escape the intended protection:

["--settings={\"disableAllHooks\":true}"]
["--settings", "{launchFiles}/settings.json"]

The first form is not inspected as JSON. The second can point at a contributed file containing protected settings and is not merged with CanvasTTY's own settings. Under the last---settings behavior documented and measured in this implementation, a later settings argument can also displace the host's hooks and sandbox even when the plugin only intended to set an ordinary option.

Required behavior: validate complete option/value pairs and normalize supported forms before merging. Either reject plugin-provided settings files or load and validate the allowed content before merging it. Keep one effective Claude settings payload with core-owned permission, hook and sandbox settings intact. Reject protected overrides regardless of whether they use an equals form, separate arguments, or a file.

This is about enforcing the selected launch profile and preserving host integration. It is not a claim that already trusted native plugin code is OS-sandboxed.

Regression coverage: exercise equals-form inline JSON, settings files, and allowed plugin settings together with core hooks in Normal and Auto. Assert both rejection of protected overrides and preservation of hooks/sandbox for allowed contributions. Check the resulting behavior with the supported real Claude CLI version as well as argv assertions.

4. P2 — Honor decision budgets longer than the supervisor's 15-second default

Code: PluginServiceSupervisor.hostCall, supervisor construction, existing long-budget test.

The manifest accepts decide.timeoutMs up to 60,000, and the hook/helper/gateway deadlines are sized accordingly. However, hostCall() uses Math.min(timeoutMs, this.options.requestTimeoutMs), and production construction leaves the supervisor at its 15,000 ms default.

A service declaring a 45-second budget and returning deny after 20 seconds is therefore replaced by the timeout's ask result at 15 seconds. Increasing the declared budget does not deliver the advertised behavior.

Required behavior: honor the validated host-call budget while retaining the normal surface-request default and an explicit bounded maximum. Keep the helper, gateway and supervisor deadlines consistent.

Regression coverage: pass a decision through an actual supervisor with a declared budget above 15 seconds and an answer after the default limit; verify the answer is retained within budget and times out beyond budget. Controlled timers are fine if the production call chain is exercised. The current 11-second gateway test bypasses the supervisor and never crosses this limit.

5. P2 — Start plugin services after the host APIs they can call are initialized

Code: early service start, later PluginSessions construction, example startup subscription.

pluginServices.sync() starts services before PluginSessions and PluginCards exist. Several asynchronous initialization steps run in between. A fast service can receive canvastty.initialize and immediately call sessions.subscribe while the optional host callback still returns undefined; the supervisor turns that into Unknown host method.

The shipped collect-demo does exactly this subscription on initialize and only logs the failure. It can remain running without the session map it needs to handle its subagents. Waiting for the start promise later does not undo the failed initialization call.

Required behavior: make service initialization happen only after the advertised host APIs and their dependencies are ready. Ensure services can subscribe before restored-session events are emitted, or reliably receive the equivalent initial snapshot.

Regression coverage: delay host startup, use a service that subscribes immediately on initialize, and verify it gets a valid snapshot and subsequent restored/new session events without a manual disable/enable cycle. Include startup calls to any other advertised APIs that have the same ordering dependency.

6. P2 — Redact complete text before selecting the agent-visible tail

Code: AgentControlService.observe/result, PluginSessions.screen.

These paths currently perform redact(tail(buffer)) or redact(plainText(buffer).slice(-limit)). If the cutoff falls inside a registered secret, its prefix is removed before matching. The remaining suffix no longer matches the full known value and need not match a generic credential pattern, so it can be returned to another agent or a screen-reading plugin.

Required behavior: mask the full available text before cutting it to the requested output size. Preserve the existing output bounds. Inspect sibling output paths for the same ordering mistake.

Regression coverage: register a custom secret that does not match a generic token shape, place it across the observation/screen cutoff, and assert no surviving fragment is exposed. Cover observe_agent, get_agent_result, and plugin screen events. Keep the existing wrapped-secret cases too.

7. P2 — Do not classify mutating Git operations as unconditional reads

Code: GIT_READ, classifyGit.

The unconditional read set includes pull, stash, config, branch, tag and other commands with mutating forms. classifyGit() returns for them before checking whether -C selects an outside repository. For example, git -C /other/repo stash pop can change another repository's worktree, and stash clear can delete its saved stashes, without adding a write/delete-outside fact.

Required behavior: separate genuinely read-only forms from mutating forms and apply the existing outside-project policy to the latter. Preserve legitimate read-only Git usage. This does not require turning the heuristic into a general shell sandbox; it requires fixing the explicit misclassification of commands the implementation already recognizes.

Regression coverage: classify outside-repository mutating stash, pull, branch/tag deletion and config-writing forms, alongside read-only status/log and appropriate listing variants. These parser tests should inspect the verdict and never execute the destructive commands.

8. P2 — Resolve the inherited stale conversation ID finding from #82

Status: addressed in the refreshed head e2de0d8 on static inspection; final validation is still required. The original finding below is retained for traceability.

Code: restored threadId assignment. Previous feedback on #82.

The combined head still unconditionally copies descriptor.threadId into the restored session even when the restore plan starts a fresh conversation, such as Reopen. Until a new lifecycle signal replaces it, persistence and later resume can still refer to the previous conversation. Closing before the new ID arrives, or running without lifecycle reporting, leaves the wrong identity attached to the new card.

Required behavior: retain the saved ID for an actual resume or an intentionally held stopped card. A fresh launch must start with no previous conversation ID; its own valid lifecycle signal can then assign the new one.

Regression coverage: restore a saved ID in Reopen mode, save again before any new lifecycle signal, and assert the old ID is absent. Repeat without lifecycle reporting. Verify that exact Resume and held stopped cards still retain the correct ID.

How to finish this PR

• Address the seven remaining open items on this branch, with a reply mapping each number to the fixing commit and focused regression coverage. Include final validation for the item 8 fix already supplied. If a finding does not apply, explain the exact production path and provide a case that demonstrates the claimed behavior.
• Preserve plugin services, launch options, environments, decision hooks, agent tools, session events, card actions and Auto. Fix the shared lifecycle/validation boundaries rather than removing the features or adding unrelated architecture.
• Run the existing required suite, typecheck and build against the final head, plus the focused cases above. Report which real CLI versions/platforms were checked and distinguish live checks from mocks. The original reported live checks are useful, but do not exercise every failure path above.
• Keep this PR Draft until the corrections and their evidence are available. We can then review the complete corrected implementation for merging into main.

The source history and authorship remain intact. Consolidating the discussion does not merge any of this code into main.

[howdeploy]

The consolidation is complete: #81–87 are closed as superseded, and #88 is the single open PR for finishing this series. The source branches were retained, and no code was merged into main.

@BIackFIame, I also saw the concurrent stack refresh to e2de0d8 and inspected the four-file delta. The new restore-plan identity handling and regression cases address item 8 of the review at the code-review level. I updated the review to acknowledge that fix; I have not run the new tests. Items 1–7 remain open, and the changes-requested status remains appropriate.

I verified that every refreshed head from #82 through #87 is contained in the refreshed #88 head. Please continue fixes here on core/7-auto-profile so the remaining implementation work and validation stay in one place.

Detailed review and remaining merge criteria.

[BIackFIame]

Thanks for the detailed review. Items 1–7 are fixed as seven new commits on top of e2de0d8; history is unchanged. Each commit has its own regression tests. Each test was run against the unfixed code first and failed there for the reason the review describes.

Final head: f705911baae8508953d3c36c1f56c97e29e921e4.

1. P1: pending or failed environment choice across shutdown and restore

Commit: 25d3dfc1fabe5ba40a05d468d066997dd3b8a15d

Root cause. The launcher's environment choice lived only on the in-memory session. The card was saved as running with no environment, so a quit during prepare, or a failed prepare followed by an app restart, restored the card as a local session.

Fix.

• The choice is now saved with the card as environmentChoice until prepare succeeds; the environment ref then replaces it.
• A saved choice that cannot be read drops the card instead of restoring it locally.
• On restore, a running card with a pending choice is held stopped. It gets the note environment-pending and a reason. Nothing is prepared or spawned until the person restarts the card, and Restart prepares again with the saved options.
• Restart refuses when the plugin that owns the choice is unavailable.
• A failed prepare keeps its choice across an app restart in the same way.
• A late prepare answer is never adopted or saved. This covers a card that was closed or restarted, or an app that is quitting. The answer is released with keepData: false, reason: "closed". This is documented in docs/plugins*.md and plugin-api.d.ts.

Tests (tests/session-environments.test.mjs):

• "quitting while prepare is pending: the choice is saved, the card comes back held, never local; Restart prepares with it". Covers a deferred prepare, shutdown, restore with no PTY, the late release, a second quit, Restart, and a plugin that is gone.
• "a failed prepare keeps its choice across an app restart; manual Restart prepares it again, never locally"
• "a saved environment choice that cannot be read drops the card instead of restoring it locally"

Live (hidden window). I used the built app with a harness plugin whose prepare never answers.

1. I created a terminal card in that environment and quit. The saved record had environmentChoice and lastState: running.
2. On relaunch the card was failed with the environment-pending note. It had no PTY child and an empty buffer, and the plugin received no request.
3. Restart ran prepare, then wrap, and a wrapped PTY started.

2. P1: initial prompt only after the asynchronous launch is ready

Commit: 38c22a3352d120be5c5cd2a91584743b6d814e83

Root cause. spawn() wrote the prompt right after create(). With launch options, an environment or a launch policy, the process was still null, so inputChecked() returned false. input() dropped that result and spawn_agent still reported success.

Fix.

• TerminalManager.deliverInput() is now the single delivery rule. A running card gets the text at once. A card whose launch is pending gets it exactly once, after that launch has started.
• Nothing is delivered in these cases: the launch is refused or fails, the card is cancelled, closed or restarted, or the launch does not start within 60 s. The caller gets the reason and the text is dropped. A per-card launch epoch, bumped on every restart, keeps dropped text out of a later launch.
• AgentControlService.spawn/send resolve after delivery. spawn_agent and send_to_agent answer a failed delivery with a non-retryable INVALID_REQUEST. The error names the session id, and the card stays.
• Plugin sessions.send waits in the same way and returns sent: false when the text was not delivered.
• The control CLI answers NOT_READY for a card whose launch is still being prepared. Before, it answered SESSION_EXITED. It queues nothing.

Tests (tests/launch-readiness.test.mjs, through ScopedOrchestrationHandler with a real TerminalManager and LaunchPipeline):

• "spawn_agent with launchOptions and a prompt: the prompt reaches the PTY once, after the plugin prepared the launch". This case also checks that a later restart gets nothing.
• "a launch policy alone (no launch options) also delays delivery; send_to_agent waits the same way"
• "a refused launch is not a delivery: spawn_agent and send_to_agent fail with the reason and nothing is written later"
• "cancelled before it was ready: the prompt is dropped, never written to a late launch"
• "plugin sessions.send waits for the prepared launch and reports a refused one as not sent"
• "the control CLI says a starting session is not ready instead of claiming the terminal exited"

Live (hidden window). I used the real orchestration-helper.mjs over MCP stdio, started by a stand-in claude in a fake HOME from the orchestrator card's own --mcp-config.

• It called spawn_agent with launchOptions and prompt.
• The harness plugin answered launch.prepare after 800 ms, and the tool answered after 911 ms.
• The child PTY received the prompt exactly once, and the child ran with the plugin's env.
• On the unfixed head the same flow answered at once and the child PTY received nothing. That run used a mocked script, review88/repro2.

3. P1: Claude settings forms and one merged payload

Commit: 51a65f63956efc0113101f2cbf5c4a9cabd5696d

Root cause. Validation looked at each argv element on its own, and it parsed JSON only when the element started with {. The merger knew only --settings <json>. So --settings={…} and settings files passed unchecked, and Claude applies only the last --settings it gets.

Fix.

• A Claude contribution's settings are checked as option/value pairs. Three forms are accepted: --settings <json>, --settings=<json>, and --settings {launchFiles}/<file> naming one of the contribution's own launch files. Such a file is read from the contribution, checked like inline JSON, and passed inline.
• The launch is refused for:
  • any other settings file
  • a value that is not a JSON object
  • a missing value
  • permissions, hooks, disableAllHooks, sandbox, defaultMode or apiKeyHelper
• The merger also handles the equals form, so each launch has one --settings that keeps the core's hooks and permissions, and Auto's sandbox.
• --bare, --safe-mode, --allowedTools, --permission-prompt-tool and --permission-prompts are core-owned for Claude. They are listed in claude 2.1.281 --help.

Tests (tests/claude-launch-settings.test.mjs):

• "protected Claude settings are refused in every form: equals, separate value, launch file, other file"
• "allowed Claude settings are normalized to one inline JSON: equals form and a launch file both work"
• "Normal and Auto: one effective --settings keeps CanvasTTY's hooks (and Auto's sandbox) with the plugin's allowed keys". This case runs the real TerminalManager and LaunchPipeline.

Live, real CLI. Claude Code 2.1.281 ran under a fake HOME with a clean environment, on local Ollama qwen3.5:9b (not pulled). The argv came from the production chain: AgentRuntimeBridge (the real hooks and decision gate), then LaunchPipeline, then resolveTerminalLaunch. Hooks were observed at a real RuntimeGateway.

Case	Result
Normal, route passed as a launch file	one --settings with env and hooks; reply "OK"; SessionStart, UserPromptSubmit, Stop and SessionEnd fired
Normal, route passed in equals form	same as the launch-file case
Old argv shape, --settings={…"disableAllHooks":true} last	no hook fired
Same contribution through the fixed pipeline	refused
Auto, route passed as a launch file	one --settings with hooks, sandbox {enabled:true, autoAllowBashIfSandboxed:false} and env; --permission-mode acceptEdits (third-party model)
Auto, touch of a file outside the project, allowed by the decision hook	the sandbox refused it: touch: …: Operation not permitted; no file
Normal, same touch	the file was created
Auto, sandbox: {enabled:false} in a launch file	refused

4. P2: decide budgets above 15 s through the real supervisor

Commit: bff160a3743ba7f043a23f1fbdc1aa58114a0b0c

Root cause. hostCall() capped every host call at requestTimeoutMs, which is the 15 s default in production. A longer decide.timeoutMs budget was cut to 15 s.

Fix.

• hostCall() keeps the caller's validated budget up to an explicit bound, MAX_HOST_CALL_TIMEOUT_MS. The bound equals MAX_DECIDE_TIMEOUT_MS, which is 60 s.
• Surface requests keep their 15 s default.
• The gateway and helper deadlines from permissionGateTimings() stay longer than the bound. The test asserts this.

Test (tests/plugin-policy-budget-secrets.test.mjs): "a decide budget above the supervisor's 15 s request default is honored through the real supervisor, and still ends at the budget". It runs DecisionHooks, then a production-configured PluginServiceSupervisor, then a real service process (tests/fixtures/slow-decide-service.mjs).

• A deny after 16 s within an 18 s budget is kept.
• An answer after a 16 s budget becomes ask.
• The test uses real timers and takes about 17 s.
• On the unfixed head it failed at 15.0 s with ask.

5. P2: services start after the host APIs are ready

Commit: 54f304405759af255fbbdd2efd3715c403bf3272

Root cause. pluginServices.sync() ran before PluginSessions, PluginCards and the plugin secrets existed. A service that called sessions.subscribe on initialize got "Unknown host method". secrets.get and cards.setBadge answered "not ready" in the same way.

Fix.

• PluginServiceSupervisor takes a waitForHost option: services wait in start() until hostReady() is called.
• index.ts calls hostReady() once all of these exist: sessions, cards, tools, secrets, the launch pipeline and environments. It does so before saved cards are restored.
• dispose() releases a start that is still waiting, and nothing is spawned.
• The ordering is documented in docs/plugins*.md.

Tests (tests/plugin-startup-order.test.mjs, with fixture tests/fixtures/startup-subscriber-service.mjs):

• "a service that subscribes on initialize gets a snapshot and restored/new events, even when the host starts slowly". It follows the index.ts order with a 400 ms host delay and checks:
  • a valid snapshot
  • answers from secrets.get and cards.setBadge
  • the restored card seen exactly once, as an event or in the snapshot
  • the created event for a new card
• "disposing before the host is ready ends the waiting start without spawning anything"

On the unfixed head the first test failed with Unknown host method: sessions.subscribe.

6. P2: redact before selecting the tail

Commit: 243778ca272d07a5bc5643b48b40bfaac3a68154

Root cause. These paths redacted after cutting the text: observe, result, the plugin screen, failure details (the last lines or 8 000 characters of the output), and the control CLI screen (the xterm viewport). A cut inside a registered secret left a tail that matched nothing.

Fix.

• The full buffer is masked first, then cut to the same bounds as before.
• The control CLI screen masks the scrollback and the viewport together, then keeps the last rows lines.

Tests. Each case places a custom secret with no generic token shape across the cutoff.

• tests/secret-redaction.test.mjs:
  • "observe_agent and get_agent_result mask the whole buffer before cutting the tail: no fragment of a custom secret survives"
  • "plugin screen text and failure details mask the whole buffer before cutting"
• tests/agent-control.test.mjs: "the control CLI screen masks a custom secret the viewport's top edge cuts"

The existing wrapped-secret cases are unchanged. The source assertion in tests/terminal-lifecycle.test.mjs now pins the new order.

7. P2: mutating Git forms

Commit: f705911baae8508953d3c36c1f56c97e29e921e4

Root cause. GIT_READ treated these as unconditional reads: pull, stash, config, branch, tag, remote, reflog, fetch and push. classifyGit() returned before the outside-project check.

Fix.

• GIT_READ now keeps only subcommands that have no changing form. gitEffect() parses the rest.
• Read-only:
  • stash list/show
  • branch/tag listing and query flags
  • config get, --get, --list, a single key
  • remote, -v, show, get-url
  • reflog, show
  • fetch/push --dry-run
• Deletes: stash drop/clear, branch/tag delete, remote remove, reflog expire/delete.
• Writes: every other form.
• With -C naming a folder outside the project, the changing forms become write-outside or delete-outside. --work-tree and --git-dir are now handled the same way.
• Inside the project nothing changed.

Test (tests/base-protection.test.mjs): "git with -C another repository: mutating forms are writes or deletes outside; read-only forms stay allowed (parsed, never run)". It checks 30 changing forms, 33 read-only forms and 7 inside-project forms. It only parses and executes nothing.

8. Final validation of the stale conversation-ID fix

I re-ran the regression tests on f705911; all pass.

• tests/session-restore-v2.test.mjs:
  • "Reopen windows starts every agent fresh and forgets the old conversation; Don't save clears the store". It saves again with no new lifecycle signal after Reopen, and switches to Continue.
  • "Continue resumes each card's own conversation and never shares the folder's latest one". This is the exact-resume case.
  • "finished cards come back stopped with Restart and Continue; skipped cards stay gone"
  • "a placed card whose environment is unavailable stays stopped and never runs locally"
• tests/launch-contributors.test.mjs:
  • "Reopen with a launch plugin starts fresh and forgets the old conversation"
  • "restore without the plugin holds the card stopped with its reason and keeps the record"
• tests/terminal-session-exact-resume.test.mjs: 3 of 3.

26 of 26 pass across these files and tests/terminal-session-restore.test.mjs.

Final head results

All of these ran with a fake HOME:

• npm run typecheck: ok
• full suite node --test tests/*.test.mjs: 1013 of 1013
• electron-vite build: ok
• audit:secrets: ok
• test:even: 47 of 47

Typecheck and the full suite also pass at every commit:

Commit	Tests
25d3dfc	997
38c22a3	1003
51a65f6	1006
bff160a	1007
54f3044	1009
243778c	1012 (the first run had one timing failure in the unrelated Even G2 SRP handshake test; the whole suite passed on re-run)
f705911	1013

Platform and what was live

• Platform: macOS 26.6.2 (25G83), Node 23.3.0, Electron 43.2.0.
• Live with a real CLI: Claude Code 2.1.281 on Ollama qwen3.5:9b (item 3 only).
• Live in the app (hidden windows, keychain stubbed):
  • item 1, with a harness environment plugin
  • item 2, with the real orchestration helper and a stand-in claude
• Mocked: all unit and regression tests. Items 4 and 5 use a real service process and the real supervisor.
• Not re-run for this review: Codex, Grok, OpenCode.