[BUG] Scheduled tasks fire but the spawned session never executes - one run reported SUCCEEDED after 12s having done nothing (recurrence of #65537)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Four Cowork scheduled tasks fired on 31 Aug 2026 and produced no effect at all: no files written, no messages sent, no notifications. The same work performed manually in the live interactive session minutes later, on the same machine and the same browser session, completed successfully three times in a row.

This looks like a recurrence of #65537 ("RemoteTrigger routines dispatch but never execute - last_fired_at updates, last_runs stays empty"), which was closed as fixed and is now locked, so I am filing a new issue as the closing notice asks.

**Failures (all times UTC)**

| # | Schedule | permission_mode | Fired | Outcome |
|---|---|---|---|---|
| 1 | `0 5 * * *` | bypassPermissions | 05:16:28.035Z, finished 05:16:40.127Z | Marked SUCCEEDED after 12 s having done nothing |
| 2 | `0 12,18 * * *` | auto | due 12:01:10Z | No effect, `last_run` absent entirely |
| 3 | same trigger, 18:00Z firing | auto | due 18:00Z | No effect, `last_run` still absent at 18:16Z |
| 4 | one-shot 21:46:00Z | auto | 21:46:13.983Z | `last_run.status` stuck at PENDING, no effect by 21:50Z |

Test 4 was a deliberately minimal pilot created to isolate the cause. It asked for three trivial steps: read the last message of one chat in a web app, append a row to an .xlsx on the linked machine, then return to the web app and send one line of text.

**Control: the same work by hand succeeds**

Immediately before test 4, in the live interactive session on the same machine, the identical three-step sequence completed successfully three consecutive times, between 23:24 and 23:34 local time. This rules out: browser closed, tab conflicts, session-takeover prompts, the permission classifier, prompt content, and folder access.

**Key contrast**

Two reminders created with `send_later`, which do not spawn a new session but deliver into the already-live interactive session (`persist_session: true`), fired at 16:30:37Z and 18:16:32Z and both executed correctly. Work delivered into a live session runs. Work that requires the scheduler to spawn a new session does not.

**Secondary issues**

1) A run that did nothing was reported as SUCCEEDED (test 1). From the outside this is indistinguishable from success, which is the most damaging part operationally. Same false positive as #60658.
2) Two scheduled firings recorded no run at all (tests 2 and 3).
3) The trigger's `last_fired_at` (05:20:54.518Z) disagrees with `last_run.fired_at` (05:16:28.035Z) for the same firing.
4) `permission_mode` is not the cause: one bypassPermissions task and three auto tasks failed identically.
5) `permission_mode` cannot be changed via `update_trigger` (only name, cron, enabled, model, prompt), forcing delete-and-recreate and losing the task's run history.

**Impact**

These tasks drive daily operations for a 30-apartment holiday-rental business: notifying the cleaning team of departure times and sending guests their arrival and departure instructions. All three daily passes had to be redone by hand, and a nightly summary failed to arrive two nights running.

Related: #47899, #56086, #51133, #60658.

### What Should Happen?

Each scheduled fire should spawn a session that actually executes the configured prompt, produces tool calls, and writes its output. A run that performed no work should never be reported as SUCCEEDED, and a run that is dispatched should always be recorded. `permission_mode` should be editable in place via `update_trigger` so a misconfigured task does not have to be deleted and recreated, losing its run history.

### Error Messages/Logs

```shell
None. That is part of the bug: no error is surfaced anywhere. Test 1 reports status SUCCEEDED, tests 2 and 3 report no run at all, and test 4 sits at PENDING. The only way to notice the failure is that the expected work simply never happened.
```

### Steps to Reproduce

1) Create a scheduled task (trigger) with a simple prompt that writes a file and sends one message, bound to a linked desktop with the browser open and logged in.
2) Wait for it to fire. Confirm via the trigger listing that `last_fired_at` advanced and a session id was assigned.
3) Observe that nothing the prompt asked for happened: no file written, no message sent, no notification.
4) Check the run status. Depending on the case it will be SUCCEEDED after a few seconds, PENDING indefinitely, or absent entirely.
5) Perform the exact same steps by hand in a live interactive session on the same machine: they succeed every time.

Reproduced four times on 31 Aug 2026 across three different triggers, two different permission modes, and both cron and one-shot schedules.

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

Cowork desktop app on Windows (exact build not captured; tasks configured with model claude-opus-5)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

The tasks run in a cloud session linked to a Windows desktop, driving the linked machine's files and browser. Trigger ids and session ids for all four failures are available on request; they are omitted here because this is a public issue.

I am happy to leave the failing one-shot pilot in place for inspection, and to re-run it on request.

Start with the scheduled-task trigger and run-status entry points, then compare a spawned session with a send_later delivery into the live session. Reproduce the one-shot pilot and trace dispatch, execution, and run recording; done means dispatched runs execute or surface an error, statuses reflect actual work, and permission_mode changes preserve run history.

索引モデルが issue の本文から書いたものです。