bug: status_line payload lacks thinkingEffort — custom footers can't follow in-session effort switches

What version of Kimi Code is running?

0.34.0

Which open platform/subscription were you using?

kimi-code subscription;第三方 provider(deepseek)下同样存在

Which model were you using?

kimi-code/k3-256k(另在 deepseek/deepseek-v4-flash 复现)

What platform is your computer?

Darwin 25.5.0 arm64 arm(macOS)

What issue are you seeing?

配置自定义 status_line.command 后,会话内切换 thinking effort(模型选择器或 /effort)时,内置 footer 立即跟随,但发给自定义命令的 payload 不含 effort 字段,且 wire 日志在切换瞬间不产生任何事件——外部 footer 只能等下一条请求的 llm.request 行才看到新值,"切换 → 下一次请求"窗口期显示旧 effort。StatusLinePayload 接口目前只有 10 个字段,没有 effort 字段;0.34.0 起会话内切换也不再写 config.update wire 行(0.33.0 会写)。

What steps can reproduce the bug?

1. 配置 [status_line] command = "node /path/to/dump.mjs"(dump.mjs 将 stdin JSON 原样写文件),/reload-tui;
2. 新开会话(k3-256k,effort 默认 high),/effort 切到 max:内置 footer 立即显示 K3-256k thinking: max,但落盘的 payload JSON 无任何字段变化;
3. 检查 ~/.kimi-code/sessions/*/session_*/agents/main/wire.jsonl:切换瞬间没有新行(profile.bind 仅会话启动出现一次,config.update 全会话 0 条),直到下一条 llm.request 才带上 "thinkingEffort":"max";
4. 对比 0.33.0(2026-08-05 发布):同一操作会在 wire 写入 config.update 行,后续请求也以新 effort 运行(实测:15:03:43 切换 → 15:03:58 请求即 max)。

What is the expected behavior?

自定义 status line 与内置 footer 一致,能即时跟随会话内 effort/模型切换。建议二选一(或都做):

1. StatusLinePayload 增加 thinkingEffort 字段(与内置 footer 的 state.thinkingEffort 同源),由 statusLinePayload() 填充;
2. 恢复 0.33.0 的会话内切换 wire 事件(config.update 行)。

Additional information

• 这是外部 status line 与内置 footer 的能力差异(生活质量问题),非崩溃类缺陷;
• 相关位置:apps/kimi-code/src/tui/components/chrome/footer.ts 的 statusLinePayload()、apps/kimi-code/src/tui/utils/status-line-command.ts 的 StatusLinePayload 接口;引擎侧 packages/agent-core-v2/src/agent/profile/profileService.ts 的 update() 存在 wire.dispatch(configUpdate(...)),但 0.34.0 运行时会话内切换未产生该行;
• 影响:外部 status line 实现(如 kimi-code-hud)无法在切换瞬间跟随,只能在下一条请求后更新——显示"最后一次请求实际使用的 effort",语义正确但滞后一次请求;
• 附带观察(待确认,可能独立于本诉求):0.34.0 下个别会话在 /effort 切换后,后续请求的 llm.request.thinkingEffort 仍保持会话启动绑定值(40/40 请求均为 high),疑似切换只更新了 TUI 显示、未作用于实际请求参数,可能与 0.34.0 新的会话传输(kap-server v2 sessions)有关,建议一并排查 session.setThinking 是否真正生效。

Start with apps/kimi-code/src/tui/components/chrome/footer.ts and apps/kimi-code/src/tui/utils/status-line-command.ts, tracing statusLinePayload() and the StatusLinePayload interface. Reproduce an in-session /effort switch and inspect the custom payload and sessions/*/agents/main/wire.jsonl. Done means the custom status line follows the switched effort immediately, with the suspected session.setThinking behavior checked separately.