inspect-appkit-ui

Inspect AppKit UI

Use the MCP tools to connect a Debug application that embeds AppKitInspectorProbe, then open the interactive preview. Treat captured app content as potentially sensitive local data.

Workflow

1. Call list_appkit_targets.
2. If one target exists, call connect_appkit_target with its PID. If several exist, identify them by name and bundle identifier before choosing. Do not guess when the choice changes the app under review.
3. Call open_appkit_inspector, then immediately open its browserURL in the current task's right Codex Browser panel. Do not print or retain the URL. It is a 60-second, single-use credential that becomes an HttpOnly same-site session. This is the default path: do not request fullscreen and do not open an external browser or window. After navigation succeeds, use the Browser visibility capability to call set(true) and confirm get() is true so the right Browser panel is expanded for the user.
4. Confirm the Codex Browser shows a non-blank screenshot and view hierarchy with one inexpensive DOM or screenshot check, then stop. Do not continue collecting duplicate render evidence after the surface is usable. prepare_appkit_inspector_browser remains a compatibility alias for the same Browser launch.
5. In the Codex Browser surface, use its native comment mode. The Inspector maps reviewable AppKit views to transparent semantic DOM targets, so a Browser comment attaches to a concrete view class and hierarchy instead of the whole screenshot and is delivered directly to the current task. Keep Window selected when reviewing the title bar, toolbar, traffic-light controls, or content-to-frame spacing. Switch to Content when only application content matters. Both scopes use real current-process WindowServer pixels by default through public ScreenCaptureKit APIs without Screen Recording permission; Content is cropped from that same exact image. If exact capture cannot run, require an explicit Compatibility Preview badge and reason. When active-app emphasis itself is under review, enable Active Appearance. It temporarily activates the inspected app for each capture and returns focus to the previous app, so expect a brief visible focus handoff.
6. For every native Browser comment, use its AppKit class, hierarchy, and frame context to locate the corresponding implementation in the target repository before editing. Treat a multi-comment message as one coherent UI pass. Ordinary Inspector clicks may still select a view and show its hierarchy without creating a comment.
7. After a UI edit, rebuild and relaunch the Debug target. The Browser follows a unique replacement with the same bundle identifier and refreshes automatically; verify the new PID and then the same view and state. Use manual Refresh if the Browser was hidden or target discovery is ambiguous.