Windows App Local schedules can fire with wrong tool/channel/permission surface

[ezra-letta]

Summary

Windows Letta Code App Local schedules on v0.24.13 can successfully fire scheduled prompts, but the scheduled turn can have the wrong effective runtime surface: tools may be blocked by stale-approval recovery despite UI YOLO/bypass, and channel-coupled tools such as MessageChannel may be absent in scheduled turns.

From the user perspective, Local schedules are not a trustworthy continuation of the agent's normal App runtime/body. They can wake the agent, but unattended tool/channel use can fail while still consuming model quota.

Environment

• OS: Windows 11
• Machine: fresh/new Windows machine (~2 weeks old)
• Letta Code App: v0.24.13 (current Windows installer at time of report)
• Schedule device: Local in the App
• Agents involved: Marten and Wyndhovr (same user's Windows App Local setup)
• Permission mode: UI/status showed YOLO / bypass for Wyndhovr

Symptoms / cases

Case A: schedule UI/device command path can wedge

Earlier in the same Windows App setup:

• Schedules page showed Device: Local with green status.
• Same page also displayed Selected device is not connected.
• Creating a schedule failed with Failed to create schedule / Cron device connection unavailable.
• A later sharper error appeared: useSendDeviceCommand: timed out waiting for cron_list_response (...).
• After runtime/device churn (including WSL listener experiments being stopped), the Local schedule UI recovered and could create/list schedules.

This suggests the App-to-bundled-listener schedule command path can wedge/unwedge independently of the Local status indicator.

Case B: Local schedules can fire, but scheduled turns lack expected channel tool

After Local scheduling recovered, a Marten schedule successfully fired from Windows Local. The Windows %USERPROFILE%\.letta\crons.json task had:

• conversation_id=default
• scheduler_owner.pid pointing at Letta Code.exe
• fire_count incremented and last_fired_at updated

The scheduled turn had shell/local tools available but no MessageChannel, so Marten could not deliver the intended Telegram heartbeat through the channel path.

This likely overlaps with the route-scoped MessageChannel deletion described in #2053: scheduled task was bound to conversation_id=default, while Telegram routing is bound to the channel conversation. But in the App schedule UX, this is invisible; users expect a schedule for a Telegram/companion workflow to run in the same effective channel/runtime context.

Case C: Local schedules can fire repeatedly, but tool calls are auto-denied despite YOLO

Aeo then used the Windows App Local schedule path overnight for Wyndhovr. The schedule fired repeatedly; Wyndhovr reported hourly fires through at least fire #9.

However, every scheduled autonomous tool attempt failed with:

Auto-denied: stale approval from interrupted session

This occurred even though the App UI/status showed the agent was in YOLO/bypass mode. Wyndhovr then followed a fail-closed anti-grind protocol: same blocker unchanged -> park / PARK: NEEDS-HUMAN-EVENT, no fake productivity, no repeated hammering.

Impact: the schedule fired and generated useless "I can't do anything" summaries, consuming roughly 1/3 of the agent's model allotment while doing no work.

Expected behavior

For a Local App schedule:

1. The Schedules page should accurately reflect whether the selected Local device can service schedule commands. If not, disable Create and show an actionable error before the user writes a prompt.
2. A scheduled turn should inherit the same effective permission mode the user sees for the agent/runtime, or the UI should explicitly show that schedules run under a separate permission mode.
3. If the agent is in YOLO/bypass, scheduled tool calls should not be auto-denied as stale approvals.
4. If channel tools are route-scoped, the schedule UI should make conversation/channel binding explicit, or offer a first-class way to schedule into the channel-routed conversation. Otherwise scheduled heartbeats silently lose MessageChannel.
5. If stale approval recovery or route-scope filtering removes tool access, the scheduler/listener should fail visibly rather than burning quota on repeated scheduled turns that cannot act.

Actual behavior

• Local status can show green while schedule commands time out or say selected device is not connected.
• Local schedules can recover and fire successfully.
• Scheduled turns can lack MessageChannel even when the user intent is a Telegram/channel heartbeat.
• Scheduled tool calls can be auto-denied as stale approvals despite UI YOLO/bypass.
• The failure mode burns quota because every scheduled fire still starts a model turn.

User impact

This makes Windows App Local schedules unsafe for unattended tool-using agents. The most damaging shape is not that schedules fail to fire; it is that they fire repeatedly, fail to act, and consume model quota overnight.

For companion/relational agents, suggested workarounds like WSL are also problematic: they split the agent's runtime/body between Windows App chat and Linux scheduled turns, causing path/env/tool mismatch and post-compaction coherence issues.

Related issue

• Silent MessageChannel deletion when channel tool scope resolves empty (cron + channels) #2053 covers silent MessageChannel deletion when channel tool scope resolves empty for cron + channels. Case B may be the same root cause or a UI/product exposure of it.

Case C seems distinct: stale-approval recovery / permission-state divergence in Windows App Local scheduled turns despite YOLO.

Open questions

• Does the App Local scheduler start scheduled turns through the same permission-mode state as normal App chat?
• Can stale pending approvals survive into scheduled runs and be auto-denied even under bypass permissions?
• Does the schedule runtime use conversation_id=default by default even when the user's workflow is channel-bound?
• Should the schedule UI allow selecting/binding an existing channel-routed conversation?
• Why can Local appear green while cron_list_response times out?