OpenClaw Parallels Smoke

Use this skill for Parallels guest workflows and smoke interpretation. Do not load it for normal repo work.

Global rules

• Parallels is postpublish-confidence coverage by default, not a prerequisite for the bounded beta-publish phase. Run it against one exact published package version and record the Validation SHA + Tooling SHA run tuple that authorized that package. Validation SHA maps to its Code SHA or Release SHA; it is not a third release identity.
• A failed postpublish Parallels lane does not retroactively unpublish a beta. Classify it as product, harness/tooling/provenance, infrastructure/credential, or wrapper failure. Only a confirmed product defect enters the next beta.
• Use one coordinator and one lane per independent guest family. Diagnose and retry one failed family once, then reassess; do not restart the aggregate matrix automatically.
• Inventory existing VMs and snapshots before provisioning anything. When a preconfigured pristine snapshot matches the requested baseline, switch to it and reuse its user, tools, and base setup. Do not create a new VM, reinstall macOS, or rebuild the guest baseline for a "fresh" run.
• "Fresh" means restoring the closest existing pristine snapshot, not creating another snapshot. Do not create ad-hoc snapshots unless the user explicitly asks or no suitable baseline exists; restore the original snapshot and leave the guest stopped after an ad-hoc run.
• Inspect the snapshot state before restoring it. A pristine poweron snapshot can contain the preconfigured logged-in session; switch to it normally so Parallels resumes that session. Do not pass --skip-resume at test entry unless the run intentionally needs to discard the saved session and boot from the login window. --skip-resume is acceptable for final cleanup that must leave the restored source guest stopped.
• Gateway verification in smoke runs should use openclaw gateway status --deep --require-rpc unless the stable version being checked does not support it yet.
• Stable 2026.3.12 pre-upgrade diagnostics may require a plain gateway status --deep fallback.
• Treat precheck=latest-ref-fail on that stable pre-upgrade lane as baseline, not automatically a regression.
• Pass --json for machine-readable summaries.
• Per-phase logs land under .artifacts/parallels/openclaw-parallels-* by default. Override with OPENCLAW_PARALLELS_ARTIFACT_ROOT when a run needs another artifact volume.
• Do not run local and gateway agent turns in parallel on the same fresh workspace or session.
• Hard-cap every top-level Parallels lane with host timeout --foreground (or gtimeout --foreground if that is the available binary) so a stalled install, snapshot switch, or prlctl exec transport cannot consume the rest of the testing window. Defaults:
  • macOS: 75m
  • Linux: 75m
  • Windows: 90m
  • aggregate npm-update wrapper: 150m If a lane hits the cap, stop there, inspect the newest /tmp/openclaw-parallels-* run directory and phase log, then fix or rerun the smallest affected lane. Do not keep waiting on a capped lane.
• Actual OpenClaw npm install/update phases are a stricter signal than whole-lane caps: install phases should normally finish within 7 minutes, and update phases should normally show meaningful progress within 5 minutes. If a phase named install-main, install-latest, install-baseline, or install-baseline-package exceeds 420s, or a phase named update-dev / same-guest openclaw update exceeds 300s without new markers, start diagnosis from that phase log and guest process state. Current Windows update phases can still pass after roughly 10-15 minutes because doctor --fix may install bundled plugin runtime deps; keep the script hard cap near 20 minutes unless the log is truly stale.
• For a full OS matrix, prefer running independent guest-family lanes in parallel when host capacity allows:
  • timeout --foreground 75m pnpm test:parallels:macos -- --json
  • timeout --foreground 90m pnpm test:parallels:windows -- --json
  • timeout --foreground 75m pnpm test:parallels:linux -- --json Keep each lane in its own shell/session and track the run directory for each one. Before starting the matrix, run any required host build/package gate to completion. When current-main tgz packaging is needed, the smoke scripts hold a shared package lock through pnpm build, inventory/staging, and npm pack; if that lock is missing or broken, serialize the matrix instead of accepting concurrent dist mutation.
• Do not run multiple smoke lanes against the same guest family at once. Tahoe lanes share the host HTTP port, and Windows/Linux lanes can collide on snapshot restore/start state if two jobs touch the same VM concurrently.
• Do not run the aggregate pnpm test:parallels:npm-update wrapper in parallel with individual macOS/Windows/Linux smoke lanes; it touches the same guest families and snapshots.
• Do not start Parallels lanes while any unrelated host command may rebuild, clean, or restage dist (pnpm build, pnpm ui:build, pnpm release:check, pnpm test:install:smoke, npm pack/install smoke, or Docker lanes that run package/build prep). Run unrelated build/package gates first, let them finish, then start the VM matrix. Concurrent dist mutation can make host npm pack fail with missing files and wastes a full VM cycle.
• While running or optimizing the matrix, record wall-clock duration per lane and the slowest phase from /tmp/openclaw-parallels-* logs. Use that timing before changing smoke order, timeouts, or helper behavior.
• If a host build changes tracked generated files such as src/canvas-host/a2ui/.bundle.hash, stop before spending VM time. Commit the generated artifact separately or fix the generator drift, then rerun the smallest affected lane.
• If main is moving under active multi-agent work, prefer a detached worktree pinned to one commit for long Parallels suites. The smoke scripts now verify the packed tgz commit instead of live git rev-parse HEAD, but a pinned worktree still avoids noisy rebuild/version drift during reruns.
• For openclaw update --channel dev lanes, remember the guest clones GitHub main, not your local worktree. If a local fix exists but the rerun still fails inside the cloned dev checkout, do not treat that as disproof of the fix until the branch has been pushed.
• For prlctl exec, pass the VM name before --current-user (prlctl exec "$VM" --current-user ...), not the other way around.
• If the workflow installs OpenClaw from a repo checkout instead of the site installer/npm release, finish by installing a real guest CLI shim and verifying it in a fresh guest shell. pnpm openclaw ... inside the repo is not enough for handoff parity.
• On macOS guests, prefer a user-global install plus a stable PATH-visible shim:
  • install with NPM_CONFIG_PREFIX="$HOME/.npm-global" npm install -g .
  • make sure ~/.local/bin/openclaw exists or ~/.npm-global/bin is on PATH
  • verify from a brand-new guest shell with which openclaw and openclaw --version

npm install then update

• Preferred entrypoint: pnpm test:parallels:npm-update
• For a macOS-only published release update check, use:
  • timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@<old-version> --update-target <target-version-or-tag> --json This keeps the same-guest openclaw update --tag ... coverage and uses the shared macOS current-user/sudo fallback without starting Windows/Linux lanes.
• Required coverage: every release/update regression run must include both lanes:
  • fresh snapshot -> install requested package/baseline -> smoke
  • same guest baseline -> run the guest's installed openclaw update ... command -> smoke again
• The update lane must exercise OpenClaw's internal updater. Do not count a direct npm install -g <tgz-or-spec> or harness-side package swap as update-flow coverage; those are install smokes only.
• For published targets, install the old baseline package first (for example openclaw@2026.4.9), then run the installed guest CLI with the intended channel/tag (for example openclaw update --channel beta --yes --json) and verify openclaw --version, openclaw update status --json, gateway RPC, and an agent turn after the command.
• For unpublished targets, pack the candidate on the host, serve the .tgz over the harness HTTP server, and point the guest updater at that served package. Prefer openclaw update --tag http://<host-ip>:<port>/openclaw-<version>.tgz --yes --json; when channel persistence also matters, pass --channel <stable|beta> and set OPENCLAW_UPDATE_PACKAGE_SPEC to the same served URL in the guest update environment. The command under test must still be openclaw update, not direct npm.
• For unpublished local-fix validation, remember the old baseline updater code still controls the first hop. A fix that lives only in the new updater code cannot change that already-running old process; the served candidate must either keep package/plugin metadata compatible with the baseline host or the baseline itself must include the updater fix.
• For beta/stable verification, resolve the tag immediately before the run (npm view openclaw@beta version dist.tarball or npm view openclaw@latest ...). Tags can move while a long VM matrix is already running; restart the matrix when the intended prerelease appears after an earlier registry 404/tag-lag check.
• Use the configured secret workflow to inject only the provider keys needed by OpenAI/Anthropic lanes. Do not print secrets or env dumps; pass provider secrets through the guest exec environment.

CLI invocation footgun

• The Parallels smoke shell scripts should tolerate a literal bare -- arg so pnpm test:parallels:* -- --json and similar forwarded invocations work without needing to call bash scripts/e2e/... directly.

macOS guest-command transport

The macOS smoke and same-guest update lanes route guest commands through scripts/e2e/parallels/parallels-exec.py; macOS hosts need python3 with its standard library. On verified Parallels 27.0.0 (58628) and 27.0.2 (58673) Apple-silicon installations, the client retains SDK login-job handles through result extraction, avoiding the host CLI's intermittent PrlJob_GetRetCode: Invalid argument failure. This error is not proof that the guest needs reinstallation or another Tools update.

Selection checks the actual prlctl on PATH and the installed CLI digest before execution. Other binaries retain ordinary prlctl; an SDK failure never retries through another transport. Root/current-user choice, raw shell-argument joining, stdin, stdout/stderr, and guest exit status are preserved. Callers still own shell quoting. Bare UUIDs use the CLI's braced lookup form; when that UUID is absent, the client checks the original literal VM name once before any guest execution. Other lookup failures are terminal. Snapshot/start/stop/input/capture and Linux/Windows execution are unchanged.

For an already-owned, running macOS guest, the same transport can be checked directly:

python3 -B scripts/e2e/parallels/parallels-exec.py --timeout-ms 30000 -- exec "<owned-macos-vm>" --current-user /bin/echo ready

Keep the outer host timeout for complete lanes; the SDK wait deadline is not proof of guest-process termination. This is a bounded workaround, not a supported public SDK integration. Revalidate ABI and live command/stdio/cleanup behavior before adding an installed-binary digest; remove the workaround after a vendor-fixed CLI is verified. Restore the original snapshot and stop the guest after ad-hoc proof.

macOS flow

• Preferred entrypoint: pnpm test:parallels:macos
• parallels-macos-smoke.sh --mode fresh --target-package-spec openclaw@<version> is an install smoke only. For published old-version -> new-version update coverage on macOS, prefer the npm-update wrapper with --platform macos; parallels-macos-smoke.sh --mode upgrade --target-package-spec ... installs the target package and does not exercise the baseline CLI's updater.
• Default upgrade coverage on macOS should now include: fresh snapshot -> site installer pinned to the latest stable tag -> openclaw update --channel dev on the guest. Treat this as part of the default Tahoe regression plan, not an optional side quest.
• parallels-macos-smoke.sh --mode upgrade should run that release-to-dev lane by default. Keep the older host-tgz upgrade path only when the caller explicitly passes --target-package-spec.
• Because the default upgrade lane no longer needs a host tgz, skip npm pack + host HTTP server startup for --mode upgrade unless --target-package-spec is set. Keep the pack/server path for fresh and both.
• If that release-to-dev lane fails with reason=preflight-no-good-commit and repeated sh: pnpm: command not found tails from preflight build, treat it as an updater regression first. The fix belongs in the git/dev updater bootstrap path, not in Parallels retry logic.
• Until the public stable train includes that updater bootstrap fix, the macOS release-to-dev lane may seed a temporary guest-local pnpm shim immediately before openclaw update --channel dev. Keep that workaround scoped to the smoke harness and remove it once the latest stable no longer needs it.
• In Tahoe prlctl exec --current-user runs, prefer explicit node .../openclaw.mjs ... invocations for the release->dev handoff itself and for post-update verification. The shebanged global openclaw wrapper can fail with env: node: No such file or directory, and self-updating through the wrapper is a weaker lane than invoking the entrypoint under a fixed node.
• Default to the snapshot closest to macOS 26.5 latest.
• On Peter's Tahoe VM, fresh-latest-march-2026 can hang in prlctl snapshot-switch; if restore times out there, rerun with --snapshot-hint 'macOS 26.5 latest' before blaming auth or the harness.
• parallels-macos-smoke.sh now retries snapshot-switch once after force-stopping a stuck running/suspended guest. If Tahoe still times out after that recovery path, then treat it as a real Parallels/host issue and rerun manually.

Windows flow

• This repo owns the general Windows VM lifecycle: remote prlctl management, clean-state checks, WSL 2, Git/Node, snapshot creation/restoration, and OpenClaw smoke. Assume Parallels Desktop is installed/activated and a Windows 11 VM has been downloaded, then run:

  pnpm test:parallels:windows:prepare -- inventory
  pnpm test:parallels:windows:prepare -- prepare
  pnpm test:parallels:windows:prepare -- verify
  

• prepare inventories before mutation, requires Parallels Tools and a logged-in desktop session, rejects OpenClaw CLI/app/tray/process state and WSL distros, creates a dated power-off clean-OS snapshot only on an unprepared guest, enables WSL/Virtual Machine Platform, installs the signed Microsoft WSL package, sets WSL 2 as default, installs Git and Node/npm, verifies the Windows hypervisor is active and no reboot is pending, and creates a power-off pre-openclaw-native-e2e-<date> snapshot.

• When today's E2E snapshot already exists, prepare restores and verifies that snapshot instead of trusting its name. Treat prepare as destructive to post-snapshot guest changes, just like an explicit restore.

• Package elevation resolves the exact version and SHA-256 from Microsoft's official WinGet manifests, validates the expected Authenticode publisher, and copies into a freshly ACL-restricted SYSTEM directory before execution. Keep this generic mechanism here; companion-specific package choices stay in the Windows app repo.

• Restore clean, e2e, an exact name, or an id:

  pnpm test:parallels:windows:prepare -- restore --snapshot e2e
  

• Restoring discards all post-snapshot changes. Inventory first and do not restore while another developer or lane owns the VM. e2e selects the newest pre-openclaw-native-e2e-*; use an exact snapshot for historical reproduction.

• For native companion work, read ../../../../openclaw-windows-node/.agents/skills/openclaw-proof-validation/PARALLELS.md. That optional macOS sidecar reuses this controller and adds only .NET, Windows SDK, WebView2, the app checkout, app-layer snapshots, build/tests, and native proof.

• Preferred entrypoint: pnpm test:parallels:windows

• Use the newest verified pre-openclaw-native-e2e-* snapshot and pass its exact name with --snapshot-hint.

• Default upgrade coverage on Windows should now include: fresh snapshot -> site installer pinned to the requested stable tag -> on the guest. Keep the older host-tgz upgrade path only when the caller explicitly passes .

Linux flow

• Preferred entrypoint: pnpm test:parallels:linux
• Use the newest versioned Ubuntu guest with a fresh poweroff snapshot. On Peter's host today, that is Ubuntu 26.04.
• If an exact requested Ubuntu VM is missing on the host, any Ubuntu guest with major version >= 24 is acceptable; prefer the newest versioned Ubuntu guest over older fallback snapshots.
• Use plain prlctl exec; --current-user is not the right transport on this snapshot.
• Fresh snapshots may be missing curl, and apt-get update can fail on clock skew. Bootstrap with apt-get -o Acquire::Check-Date=false update and install curl ca-certificates.
• Fresh main tgz smoke still needs the latest-release installer first because the snapshot has no Node or npm before bootstrap.
• This snapshot does not have a usable systemd --user session; managed daemon install is unsupported.
• The Linux smoke now falls back to a manual setsid openclaw gateway run --bind loopback --port 18789 --force launch with HOME=/root and the provider secret exported, then verifies gateway status --deep --require-rpc when available.
• The Linux manual gateway launch should wait for gateway status --deep --require-rpc inside the gateway-start phase; otherwise the first status probe can race the background bind and fail a healthy lane.
• If Linux gateway bring-up fails, inspect /tmp/openclaw-parallels-linux-gateway.log in the guest phase logs first; the common failure mode is a missing provider secret in the launched gateway environment.

Discord roundtrip

• Discord roundtrip is optional and should be enabled with:
  • --discord-token-env
  • --discord-guild-id
  • --discord-channel-id
• After a successful Discord smoke/roundtrip, shut down the guest VM before handoff (prlctl stop "$VM_NAME" or the concrete VM name). The macOS smoke harness should do this automatically after successful Discord proof; still stop the VM manually after ad-hoc Discord checks. Do not leave the Discord-configured guest running; it can keep reading/posting in #maintainer and spam Discord after the proof is complete.
• Keep the Discord token only in a host env var.
• Use installed openclaw message send/read, not node openclaw.mjs message ....
• Set channels.discord.guilds as one JSON object, not dotted config paths with snowflakes.
• Avoid long prlctl enter or expect-driven Discord config scripts; prefer prlctl exec --current-user /bin/sh -lc ... with short commands.
• For a narrower macOS-only Discord proof run, the existing parallels-discord-roundtrip skill is the deep-dive companion.