Fixes#65465. Caps the compaction reserveTokensFloor so that at least min(8 000, 50%) of the context window remains available for
prompt content, preventing the default 20 000-token floor from exceeding the entire context window on small-context local models (e.g. Ollama
16K). The cap is only applied when contextTokenBudget is provided, preserving backward compatibility.
* fix(wizard): avoid trim crash on missing provider ids
Guard provider id comparisons in setup-mode model selection policy so setup does not crash when plugin provider metadata is missing an id.
Fixes#66641Fixes#66619
Made-with: Cursor
* test: fix wizard provider-id regression coverage
* fix: avoid setup crash on missing provider ids (#66649) (thanks @Tianworld)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* fix: forward optional params dropped at the runEmbeddedAttempt call site
runEmbeddedPiAgent in pi-embedded-runner/run.ts hand-enumerates ~85 fields
when calling runEmbeddedAttempt({...}). Several optional fields on
RunEmbeddedPiAgentParams were added to the type and to attempt.ts (the
consumer) but were never wired at this specific call site. Because every
field is declared as ?: optional on EmbeddedRunAttemptParams, TypeScript
does not flag the missing fields and the attempt silently receives
undefined for each.
Four fields were affected:
- toolsAllow (#58504, #62569): cron's --tools allow-list. Persisted in
jobs.json by the CLI, forwarded by cron/isolated-agent/run-executor.ts
to runEmbeddedPiAgent, but dropped here. Result: provider request
ships the full tool catalog on every cron run regardless of toolsAllow,
defeating the ~95% input-token reduction documented in #58504 and the
--tools restriction documented in docs/automation/cron-jobs.md:85.
- disableMessageTool: cron/isolated-agent/run-executor.ts:164 sets it
from toolPolicy.disableMessageTool, derived at run.ts:110 as
`params.deliveryContract === "cron-owned" ? true : params.deliveryRequested`.
Every cron-owned delivery (the default per docs) is supposed to disable
the message tool so the runner owns the final delivery path. Without
forwarding, the agent can call messaging tools mid-cron and cause
duplicate or wrong-channel sends.
- requireExplicitMessageTarget: cron/isolated-agent/run-executor.ts:163
sets it from toolPolicy.requireExplicitMessageTarget. Has a fallback at
attempt.ts:568-569 to `?? isSubagentSessionKey(params.sessionKey)`, so
non-subagent crons silently get false instead of the intended value.
- internalEvents: agents/command/attempt-execution.ts:478 passes it via
params.opts.internalEvents. Different caller path from cron, but the
same drop point. Internal events array silently dropped before reaching
the consumer at attempt.ts:1480.
The fix is four lines in the runEmbeddedAttempt({...}) call, immediately
after the bootstrapContextMode/bootstrapContextRunKind lines added by
PR #62264 (which fixed two more fields with the identical pattern at the
same call site).
A regression test (run.attempt-param-forwarding.test.ts) covers all six
optional fields shown to have been bitten by this class of bug at this
seam. The next ?: optional field added to RunEmbeddedPiAgentParams without
wiring at the runEmbeddedAttempt call site will fail a test instead of
silently shipping broken — addressing the missing-guardrail concern PR
#60776's writeup explicitly noted.
Verified locally: 6/6 forwarding tests pass, 258 pi-embedded-runner/run*
tests pass, 176 cron/isolated-agent tests pass, oxlint and tsgo deltas
versus origin/main are zero.
Fixes#62569
* test: distill param forwarding guardrails
* fix: restore embedded-run param forwarding (#62675) (thanks @hexsprite)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
