问题
request-help 的 completion_criteria.any/all[].url_matches 目前只受字符串类型约束。扩展在 human-loop.ts 中把它交给 JavaScript RegExp，同步匹配主标签页 URL；完成条件会在请求开始时检查一次，此后每 500 ms 轮询。
例如在主标签页 URL 为 https://app.example/ + 28 个 a + ! 时，条件 {"url_matches":"(a+)+$"} 会触发灾难性回溯。本机 Node/V8 的受控测试中，同类 URL 使用 26 个 a 已耗时约 655 ms；实际耗时依运行环境变化。同步匹配期间，超时计时器不能中断正则，扩展后台线程也无法及时处理后续工作。
影响边界
需要 agent 提交恶意或意外的 url_matches 条件。现有证据不表明仅访问远程网站即可触发。主要影响是扩展的可用性，以及人工协助的完成检测、取消和其他后台事件的响应时间。
期望结果
- URL 完成条件的匹配耗时具有明确上界；不能仅依赖正则长度限制或外部计时器。
- 不支持的模式在进入人工等待前返回清楚的参数错误。
- 回归测试覆盖回溯型模式、正常 URL 匹配，并确认扩展随后仍能处理取消等事件。
可选修复方向包括线性时间正则引擎，或明确收紧为 URL 通配规则；若改变现有正则语义，需要说明兼容行为。
问题
request-help的completion_criteria.any/all[].url_matches目前只受字符串类型约束。扩展在human-loop.ts中把它交给 JavaScriptRegExp，同步匹配主标签页 URL；完成条件会在请求开始时检查一次，此后每 500 ms 轮询。例如在主标签页 URL 为
https://app.example/+ 28 个a+!时，条件{"url_matches":"(a+)+$"}会触发灾难性回溯。本机 Node/V8 的受控测试中，同类 URL 使用 26 个a已耗时约 655 ms；实际耗时依运行环境变化。同步匹配期间，超时计时器不能中断正则，扩展后台线程也无法及时处理后续工作。影响边界
需要 agent 提交恶意或意外的
url_matches条件。现有证据不表明仅访问远程网站即可触发。主要影响是扩展的可用性，以及人工协助的完成检测、取消和其他后台事件的响应时间。期望结果
可选修复方向包括线性时间正则引擎，或明确收紧为 URL 通配规则；若改变现有正则语义，需要说明兼容行为。