MicroVM: Claude Code hangs on "Managed settings

On dev (2026-10-18), Claude Code tasks 5118 and 5119 (account acct2, project mr-6382) placed on MicroVM node gmind-microvm-1 sat "Running" for 10+ minutes. The live console shows Claude Code's dialog "Managed settings require approval … OTEL_EXPORTER_OTLP_LOGS_ENDPOINT / OTEL_EXPORTER_OTLP_METRICS_ENDPOINT … Approving applies: env vars ×2", with nobody to answer it. Static-node Claude runs never stop there. Likely cause (code reading): - On static nodes, consent is pre-written to <cfgdir>/remote-settings-consent.json (apps/jaahd/plugin_repair.py:416-427, :532-586; converged before spawn at apps/jaahd/fleet_dispatch.py:1230-1232). As a backstop, consent_watch presses Enter on the dialog (apps/jaahd/fleet_dispatch.py:1463-1470, apps/jaahd/consent_watch.py:1-12; the dialog is listed in apps/jaahd/agents/claude.py:45-47). - apps/jaahd/microvm_session.py:719-735 copies the consent file into the guest, but nothing in microvm_session.py runs consent_watch or an equivalent. So a consent record the guest CLI does not accept (hash, or org/account resolution; see :129-134) leaves the dialog unanswered. Fix: give the MicroVM launch the same backstop (the guest's tmux pane watched by consent_watch, or a guest-side equivalent). Also find why the copied consent does not satisfy the guest CLI. Out of scope: changing the org's telemetry settings; ACP-runtime engines in the guest (draft 7551); the launch race (draft 7504). Done means: - A Claude Code subscription task on a MicroVM node passes the managed-settings dialog unattended, asks its question, and ends done with a merged PR. - A jaahd test covers the MicroVM launch starting the consent backstop. Required checks: ./dc check full

MicroVM runners now get the consent-dialog backstop (consent_watch.watch_vm on the VM console) plus tests; root cause: guest approvals never reach the host peer scan (draft 7572). PR #6124 merged. Full gate red only on develop's own failures (draft 7665); live oracle unverified.