[Feature] 定时任务（scheduled_tasks）缺少 permissionMode 配置：无人值守运行时工具调用等 120 秒后被自动拒绝

[hawchou1995]

Problem / 问题

环境

• PI-Desktop 0.15.3（本机实测 PI-Desktop.exe FileVersion / ProductVersion；反馈按钮也会自动带入 app-version，以按钮带入值为准）
• 宿主：pi-desktop-host-core（Rust），数据库 %USERPROFILE%\.pi-desktop\pi.sqlite
• 场景：用户在应用内创建定时任务（scheduled_tasks，cadence=daily|weekly），希望其在应用无人操作时自动跑完一条多步流程

Proposed change / 期望改动

为无人值守场景创建的定时任务，应当可以（在其自身配置或全局设置里）指定会话权限模式，例如 auto；或者至少在 UI/文档中明确告知：定时任务会话固定以 ask 运行，且无人在旁点击批准时，需要审批的工具调用会在 120 秒后被自动拒绝。

实际行为

1. 定时任务派发出来的会话，sessions.permission_mode 固定为 ask，不受以下任何一项影响：
   • 应用默认权限模式（本机 kv app.app.defaultPermissionMode = "accept-edits"）
   • 交互式会话里手动选中的 auto（同一账号下另一个交互会话确实是 auto）
   • 在任务 config_json 里显式写入 {"config":{"permissionMode":"auto"}}（见下方「已尝试的绕法」）
2. 于是无人值守时，凡是被判定为「需要审批」的调用，会阻塞等待 120 秒然后被拒绝，任务继续往下跑但该步骤丢失。

复现步骤（最小）

1. 创建一条定时任务，prompt 要求执行任意一条复合/多目的 PowerShell 命令（例如一条里同时做「报告时间 + 列出若干路径是否存在 + 调一次本地服务探活」）。
2. 把触发时间设为 2–4 分钟后，然后离开电脑、不要点任何批准弹窗。
3. 触发后观察：该次 Bash 调用在 audit_log 里出现 kind='tool_denied'。

   {"commandShellId":"windows-powershell","externalPathPermission":false,"mode":"agent",
    "permissionWaitMs":120014,"prompted":true,
    "toolCallId":"call_00_xam6HyMZ46Mz66SsR07D7980","toolName":"Bash","totalMs":120014}

   实测两次触发各出现一次 permissionWaitMs≈120000 的拒绝；同一次会话里，其余只读/单一目的命令则以 prompted:false, permissionWaitMs≈2ms 正常通过。

统计口径（本机 3 个定时任务会话的 audit_log 汇总）

tool	总数	弹审批	被拒	成功	累计等待(s)
Bash	282	8	5	238	730.3
Read	31	1	0	31	37.4
Edit	14	1	0	14	3.1
Glob	3	2	0	3	220.0
Write	1	0	0	1	0.0

也就是说：绝大多数命令会被自动放行（这点体验很好），但没有任何办法把剩下那 2%–3% 的命令在上线前一次性授权，只能靠人守在那里点。对于「周一 08:00 自动出周报」这类任务，等于把无人值守变成了「必须有一个人在 8 点前后守着」。

已尝试的绕法（均无效，供参考）

直接在 scheduled_tasks.config_json 里加键：

{"calendarConfigured":true,"mode":"agent",
 "nextRunAt":1790553600000,
 "schedule":{"hour":8,"minute":0,"weekday":0,"weekdays":[0]},
 "workspacePath":"D:/Documents/项目",
 "config":{"permissionMode":"auto"}}

→ 下一次派发的会话 sessions.permission_mode 仍然是 ask。补充观察：通过 ScheduledTaskUpdate 更新同一任务后，这个 config 键被原样保留（说明 config 是已知字段、只是不承载权限模式），所以问题不在于写入方式。

Alternatives / 其他方案

建议（任选其一即可解决问题）

1. 任务级：ScheduledTask* 工具与任务 UI 增加 permissionMode（ask / accept-edits / auto）选项，落进 config_json.config.permissionMode 并在派发时生效；
2. 应用级：设置里给「定时任务默认权限模式」一个开关（可默认仍为 ask，但允许无人值守场景主动改成 auto）；
3. 兜底：批准弹窗增加「本任务始终允许此命令模式」选项，把授权持久化成可管理的规则列表（当前只观察到一次性批准）；
4. 至少：在定时任务创建界面与工具描述里写明「无人应答 120 秒后工具调用会被拒绝」，避免使用者按字面理解成真无人值守。

影响面

任何依赖「应用在跑、人不在」的自动化都会踩到：本机另有一条每日 08:00 的定时任务，在 251 次工具调用中被拒 2 次、累计在审批上等待 513 秒（其中两次是人在旁边点掉的 100 秒以上的等待）——说明这是通用问题，不是单条任务的偶发。

Additional context / 补充信息

附：本机已做的规避（不依赖上游修复）

把多步流程收敛成「一个编排脚本 + 少量判断型命令」，使每周需要审批的命令数从数十条降到个位数；并在任务 prompt 中要求「命令写成单一目的、被拒后改走更简单的等价命令、被拒命令逐条列进汇报」。

[hui455]

感谢反馈！这个需求已由 #863 实现，并已包含在 v0.15.4 中 ,可以升级后试一下。