P0: Workbench visible ACP Mac-control cannot consume session MCP

[100yenadmin]

Summary

Signed installed-app Mac-control proof is blocked because the visible Workbench/OpenClaw agent path accepts the proof prompt but does not produce Mac-control tool calls. This is different from support-control/CLI smoke: support/canary connector gates can pass while the visible first-party agent still never calls desktop_* tools or performs a real low-impact desktop action.

Evidence

• Tracker: Sprint: Mac Control Contract Unification + Matt-Style Reconciler #480
• Related release gate: Add exact-path Computer Use release gate for Workbench hotfix #437
• Candidate Workbench head: ed458a05c9c62d5f2a6cac1fef725bc9968c31ba
• Signed Manual Build run: 28470180732
• Installed app target: /Applications/evaOS Workbench.app
• Installed-app proof passed under /Volumes/LEXAR/Codex/evidence/evaos-workbench-mac-control/ed458a05c9c62d5f2a6cac1fef725bc9968c31ba/installed-app-proof-28470180732/
• Full doctor packet: /Volumes/LEXAR/Codex/evidence/evaos-workbench-mac-control/ed458a05c9c62d5f2a6cac1fef725bc9968c31ba/mac-control-doctor-full-20260630T204821Z/
• All non-visible gates passed in that packet; visible_agent_mac_tools failed.
• Workbench DB recorded the prompt, then a tips row with ACP_EMPTY_TURN.
• ACP replay for the Workbench session showed only session_info_update, available_commands_update, user_message_chunk, and session_info_update; it did not include tool_call, tool_call_update, or agent_message_chunk for Mac-control.

Required behavior

The visible proof must validate the actual Workbench/OpenClaw visible-agent control path, not only internal support-control CLI smoke.

The agent should:

1. Run first-party Mac-control status/capability tools for the selected support/canary target.
2. Call desktop_see through the Mac-control tool surface.
3. Perform one approved low-impact visible action on the controlled support Mac, such as opening TextEdit/Notes and typing a nonce.
4. Return audit evidence for the tool calls/action.
5. Prove desktop_control_stop, revoke/post-reset recovery, and kill-switch fail-closed behavior.

Acceptance

• scripts/evaosMacControlDoctor.js classifies this failure as a typed blocker such as visible_agent_no_tool_dispatch, not generic runtime_not_configured.
• The visible-agent gate requires durable evidence of actual tool events, not just final assistant text or support CLI output.
• Required tool evidence covers customer_mac_status, customer_mac_capabilities, desktop_control_status, desktop_see, desktop_bridge_audit_tail, desktop_control_stop, and desktop_kill_switch.
• The proof fails if the Workbench ACP replay/DB contains only a user prompt and session metadata.
• The proof fails if the low-impact desktop action is not executed through the visible agent's Mac-control path.
• The proof remains scoped to support/canary targets only. Do not touch Matt's setup.

Boundary

This issue does not claim release/customer readiness. It is a release blocker until signed installed /Applications/evaOS Workbench.app visible-agent proof passes end to end and #480 is updated with evidence.

[coderabbitai]

🔗 Related PRs

#391 - Restore beta3 Mac pairing baseline [merged]
#403 - fix: recover Mac control installed app states [merged]
#449 - Fix legacy app stale owner proof path [merged]
#462 - [codex] Document Workbench release proof lanes [merged]
#476 - Harden installed Mac-control proof scope [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!