nucleic/nucleic
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge nucleic/olive-iris-panda-dfdi into dev

Browse Source
This commit is contained in:
abkslm
2026-07-26 21:03:13 -07:00
parent 29be086189
commit 1051e1c607
6 changed files with 158 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/LINUX_VM.md
+8
View File
@@ -167,6 +167,14 @@ session's own disposable Linux VM. Advertised (and pre-allowed) whenever the Lin
`MCPApprovalServer.VMControlCall`/`VMControlReply` and `ClaudeCodeBackend.performVMControl` with the
macOS tool — see [MACOS_VM.md §8.3](MACOS_VM.md) for the full op table and rationale.
One deliberate divergence: the prose. `maxConcurrentVMs` is a **macOS-guest** ceiling (macOS itself
limits simultaneous macOS guests — [MACOS_VM.md §10.1](MACOS_VM.md)), and Linux guests don't share
it. So the macOS tools carry `MCPApprovalServer.macVMFreeWhenIdleNotice` — a MANDATORY "free the VM
the moment you stop actively using it" duty, since one agent parking an idle macOS VM blocks every
other agent's boot — while `linux_vm_control` says the opposite out loud ("NOT capped the way macOS
VMs are"). Borrowing the macOS scarcity prose here would be false and would buy nothing but
suspend/resume churn.
## Settings
`MacVMSettings` (in `Project.swift`), all off/pinned by default:
docs/MACOS_VM.md
+14 -2
View File
@@ -427,8 +427,8 @@ manager already owns. One `op`:
| --- | --- |
| `status` | Read-only: reports `running` / `suspended` / `stopped` (disk clone present) / `absent`. |
| `stop` | Power off, keep the disk clone (frees host RAM; the next VM command reboots it). |
| `suspend` | Pause/freeze in place (`VZVirtualMachine.pause` — keeps RAM, halts CPU). |
| `resume` | Thaw a suspended guest (`VZVirtualMachine.resume`). Reuse (`ensureRunning`) also auto-resumes, so `suspend` is transparent to a later exec. |
| `suspend` | Pause, save the runtime state to disk, power off — frees the guest's RAM **and its slot** (falls back to a RAM-pause if the save can't be made). |
| `resume` | Restore a suspended guest from its saved state. Reuse (`ensureRunning`) also auto-resumes, so `suspend` is transparent to a later exec. |
| `restart` | Stop → reboot in place (reclaims the RAM a long-running VM holds). |
| `kill` | Stop **and** delete the disk clone (the next VM command boots a fresh one). |
@@ -440,6 +440,18 @@ advertised (and pre-allowed) whenever the session can use the macOS VM at all, i
[LINUX_VM.md](LINUX_VM.md)); both share `MCPApprovalServer.VMControlCall`/`VMControlReply` and
`ClaudeCodeBackend.performVMControl`.
**The free-when-idle duty.** Because concurrent macOS guests are hard-capped (`maxConcurrentVMs`,
§10.1), an agent that parks an idle VM blocks every *other* agent's boot — so the duty to free it is
stated as MANDATORY, and `MCPApprovalServer.macVMFreeWhenIdleNotice` is appended to **every** macOS-VM
tool description (`mac_vm_exec`, `mac_vm_computer`, `mac_vm_computer_batch`,
`mac_vm_clear_notifications`, `mac_vm_request_operator`, `mac_vm_control`), not just the lifecycle
tool: the agent has to see it wherever it touches the VM, not only if it happens to read
`mac_vm_control`. It says: the moment you stop *actively* using the VM — including mid-turn, before
reading files or running container work — `suspend` (need it again), `stop` (state is disposable), or
`kill` (done with it). `SessionController.sandboxBuildGuidance` repeats it in the system prompt. The
Linux tools deliberately carry the *opposite* wording, since Linux guests are uncapped
([LINUX_VM.md](LINUX_VM.md) §Lifecycle control).
---
## 9. Settings