1. Create a recurring cron job with:
- `schedule.kind = "cron"`
- `sessionTarget = "isolated"`
- `payload.kind = "agentTurn"`
- model = `openai-codex/gpt-5.4`
- `timeoutSeconds = 60`

2. Use even a very small prompt, for example:
- `Use the message tool with action='send', channel='slack', to='<target>' and message='DEBUG recurring minimal cron'. Do not write anything else.`

3. Trigger the recurring job manually with force-run.

4. Wait for the run to complete.

5. Observe that it ends with:
- `Error: cron: job execution timed out`

6. Check diagnostic logs and observe:
- `FailoverError: LLM request timed out.`

7. Then create an equivalent one-shot cron job with:
- `schedule.kind = "at"`
- same model
- same `sessionTarget = "isolated"`
- same or equivalent prompt

8. Let the one-shot job run.

9. Observe that the one-shot job succeeds, including cases with tool use and moderately structured prompts.

Recurring cron jobs using `sessionTarget: "isolated"` and `payload.kind: "agentTurn"` should execute successfully when force-run, just like equivalent one-shot `schedule.kind = "at"` jobs.

If the prompt is valid and the model/tool path works for one-shot jobs, the same logic should also work for recurring cron jobs without timing out.

Recurring cron jobs consistently fail when force-run, even with very small prompts.

The run ends with:
- `Error: cron: job execution timed out`

Diagnostic logs show:
- `FailoverError: LLM request timed out.`

This happens even for minimal recurring jobs that only call `message.send` with a fixed string.

By contrast, equivalent one-shot `schedule.kind = "at"` jobs succeed.

Medium to high.

This breaks confidence in recurring cron jobs that rely on isolated `agentTurn` execution with LLMs, especially when users use force-run to test scheduled automations before relying on them.

The issue can make a recurring automation appear broken even when equivalent one-shot jobs succeed, which is confusing and can cause missed reminders or failed workflows.