GitHub用户反馈
LLM 控制 iPhone 时无法识别镜像窗口的 Mac 登录锁屏状态
用户报告 phone-harness 在 iPhone Mirroring 显示 Mac 登录锁屏时仍返回连接就绪，导致 agent 按流程向密码输入框输入。该工具用 OCR 检测阻塞状态，但关键字列表未覆盖锁屏文案，暴露了基于屏幕镜像的 agent 控制方案在状态识别上的安全盲区。
查看原始信号github:ShawnPana/phone-harness
目标用户
希望用 LLM agent（如 Claude Code）直接操作自己真实 iPhone 的开发者，agent 需要跨应用执行点击、输入等交互。
潜在需求
在 agent 控制手机的过程中，需要可靠识别镜像窗口的各类阻塞/中间状态，尤其是带凭据输入框的锁屏，避免 agent 把输入发送到错误目标，并据此中止或提示人工介入。
发生场景
用户通过 macOS Sequoia 的 iPhone Mirroring 让 LLM agent 控制真实 iPhone。iPhone Mirroring 闲置后进入 Mac 登录锁屏界面，但工具的 connection_state() 仍返回 'ready'，agent 会继续执行 tap_text/type_text，将后续输入写入密码字段。
来源证据
当 iPhone Mirroring 窗口显示 Mac 登录锁屏时，phone-harness 的 connection_state() 仍返回 'ready'，导致 agent 可能向密码输入框输入内容。
connection_state() returns 'ready' on the Mac-login lock screen — agent can type into the password prompt `connection_state()` returns `'ready'` while the mirroring window is showing the Mac-login lock screen, so an agent following `SKILL.md` will treat the session as live and start tapping and typing into a **password prompt**. ### Reproduction Leave iPhone Mirroring idle until it locks. The window shows: ``` iPhone Mirroring Is Locked Touch ID or enter the Mac login for "<Name>" to continue.https://github.com/ShawnPana/phone-harness/issues/5
为什么值得留意
这个 issue 直接展示了基于 OCR 的自动化工具在真实锁屏状态下的失效，且后果是输入可能进入密码框，属于高风险误操作。它说明要让 agent 可靠控制真实手机，仅靠简单 OCR 关键字检测不够，需要更鲁棒的锁屏/凭据界面识别，这是该方案能否被可信采用的关键缺口。
已有方案
- phone-harness 利用 iPhone Mirroring 窗口作为传输，通过 screencapture + Vision OCR 获取界面状态，并使用 _BLOCKED_MARKERS 关键字列表识别阻塞状态
未满足部分
- 现有 OCR 阻塞状态检测未覆盖 Mac 登录锁屏文案，误报 'ready'
- 没有机制在检测到凭据输入框时阻止 agent 继续输入
可能延伸 · 模型推测
- 可将锁屏/凭据界面识别推广到其他基于屏幕镜像的自动化工具（推测）
- 在检测到凭据界面时自动暂停 agent 并请求人工确认（推测）
目前未知
- 该 issue 来自单个用户报告，影响范围未知
- 项目仍处早期，实际用户数量和采用程度不明
继续核实
- 在 phone-harness 的日常使用中，Mac 登录锁屏状态出现的频率有多高？
- 除 'iPhone Mirroring Is Locked' 外，还有哪些镜像窗口中间状态可能被误判为 'ready'？
- 其他基于屏幕镜像控制手机的工具是否也面临类似的状态识别盲区？
主题词
phone automationscreen ocrstate detectionlock screen detectioncredential prompt safety