[mvanhorn]

Pi Dreamer tasks configured with a timeout longer than 30 minutes still terminate after 30 minutes, even when the task is actively producing events. The Pi subprocess runner imposed a hardcoded 30-minute timeout that could expire before the executor’s per-task timeout and abort signal.

The runner now receives the task’s configured timeout in milliseconds, defaulting to 30 minutes when unspecified. A regression test verifies that a 120-minute task forwards the expected timeout while leaving fallback model handling with the shared executor.

Ran npm test locally on macOS for the magic-context createPiDreamerClient change; it hit its time limit before finishing.
Tests for the magic-context createPiDreamerClient change live in packages/pi-plugin/src/dreamer/index.test.ts.
The tests in packages/pi-plugin/src/dreamer/index.test.ts fail without the fix in the magic-context createPiDreamerClient change (checked by reverting the source changes).

Harness coverage (required)

For each entry select: covered / not applicable — surface does not exist there / NOT covered.

• OpenCode 1:
• OpenCode 2:
• Pi:
• OMP:
• Rust module:

Issue 784.

---

Summary by cubic

Fixes Issue 784: Pi Dreamer tasks configured with a timeout longer than 30 minutes were cut off at 30 minutes because the subprocess runner imposed a hardcoded wall-clock limit. The runner now uses the task's configured timeout_minutes (defaulting to 30 minutes when unset) plus 5 minutes of headroom, so the executor's abort signal always ends the run first.

Also maps the Pi user-memory review child title to its configured task (review-user-memories) so the child gets that task's timeout and records under the expected name. Regression tests confirm a 120-minute task forwards its timeout plus headroom, an unconfigured task uses the default, and fallback model handling stays with the shared executor.

^{Written for commit 6645062. Summary will update on new commits.}

Confidence Score: 5/5

The PR appears safe to merge, with no blocking findings.

Summary

Pi Dreamer now gives each child process its task’s configured timeout plus five minutes of headroom.

• Pi Dreamer runner deadlines follow each task's timeout.
• Pi user-memory child sessions use the configured task name.

No code changed since the previous review. No previous findings were supplied, and no new rule violations were found. Tests were not run during this review.

_{Reviews (4) · Last reviewed commit: "fix(dreamer): honor Pi Dreamer per-task ..." · Reviewed by Greptile}

[github-actions]

This PR needs a linked issue with the design-approved label before it can be reviewed or merged. Link the approved issue with Approved issue: #<issue> (or Refs #<issue>) in the description. A maintainer will apply the design-approved label on the issue, or trivial on the pull request when there is genuinely no design to agree. The issue stays open until the change ships; maintainers take care of it then.

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[magic-alfonso]

Thanks @mvanhorn. I pushed two follow-ups and then squashed the PR into a single commit, with you as its author: the subprocess ceiling now sits five minutes above the task timeout so the executor's own timeout always ends the run, and the user-memory review child maps to its configured task. The squash only drops the issue-closing keyword from the commit message, so issue 784 stays open until the release ships. It merges once the checks pass.