fix(cron): preserve active listener execution by default

[overlord-letta]

Summary

• Restore the original execution locality for implicit Cloud-agent schedules: keep the timer durable in Cloud, but persist the active registered listener as the preferred target.
• Carry the listener device identity through tool runtime context so a child letta cron command cannot select a stale installation ID.
• Keep explicit choices authoritative: --computer selects a device, --runner cloud selects the Cloud sandbox, and --runner local stays process-local.
• Reject implicit targets that are offline, unregistered, synthetic, Desktop-local, or managed sandboxes instead of silently moving the work to Cloud.

Before / after

Before, letta cron add without runner flags omitted target_device_id, so work created on a connected listener ran in the Cloud sandbox.

After, the CLI resolves the listener that owns the current turn, verifies that it is a live external environment, and stores it in the existing target_device_id field. Existing targetless schedules keep their historical Cloud-sandbox behavior.

Limits

Managed sandboxes and Desktop local-proxy connections are not accepted by the current Cloud schedule target API. The CLI reports that limit and gives explicit alternatives instead of claiming local execution.

Test plan

• bun test src/cli/subcommands/cron.test.ts src/cli/subcommands/cron-runner.test.ts src/backend/api/client.test.ts src/tools/shell-env.test.ts (64 pass)
• bun run check (12/12 checks pass)
• Copied the HTTP-boundary regression onto the parent commit; the three default-target cases fail there and pass with this change.
• Built the branch CLI, launched an isolated registered listener, created a real one-shot schedule with no runner or computer flag, and waited for it to fire. letta cron runs reported status: success, delivery: device, and the exact listener connection. The temporary schedule and listener were removed.
• GitHub CI is fully green across all platform, headless, integration, build, lint, and review jobs.

👾 Generated with Letta Code

[just-cameron]

https://linear.app/letta/issue/LET-10543/schedules-invoked-from-an-available-listener-execute-in-cloud-instead

[cpacker]

Pushed 4c1ad53: managed sandboxes no longer error on default letta cron add — they fall through to the untargeted schedule, which already fires in the agent's Cloud sandbox. That was the pre-existing behavior and is the locality-preserving answer for that runtime, so requiring --runner cloud there just broke the most common no-flags path.

Behavior matrix for default letta cron add (cloud agent) after this commit:

Runtime	Result
Registered external listener (VPS, letta server)	Cloud schedule targeted to that listener
Managed cloud sandbox (sandbox-* runtime id)	untargeted Cloud schedule → fires in the sandbox (unchanged from main)
Desktop-local / unregistered / offline runtime	error with --runner cloud / --computer / --runner local guidance

Implementation: validateInferredTargetDevice became resolveInferredTargetDevice, returning device / cloud-sandbox / error. The sandbox-* check runs before the environments-registry lookup (and skips it entirely) because sandbox rows can be registered and online in the registry, but individual sandboxes get retired and recreated, so pinning one as a device target would be wrong. Prompts, --help, and the scheduling skill updated to match; HTTP-boundary test added asserting the sandbox path POSTs without target_device_id and never hits /v1/environments/.

Known remaining gap (follow-up, not this PR): desktop-local sessions still error on the default. They exist only in the desktop's local proxy, not the Cloud environments registry, so Cloud dispatch has no wire to deliver on — making them targetable requires registering the desktop listener in the environments registry first.

👾 Generated with Letta Code