Goose 1.57.0 fixes scheduled runs ignoring recipe settings

A fix affecting automated work directly

Goose 1.57.0 was released at 19:26 UTC on 28 October 2026, early 29 October in Vietnam. It fixes the scheduler ignoring a recipe's settings and falling back to global configuration, potentially selecting an unintended model or execution parameter.

A recipe is a reusable task definition containing instructions and settings. Teams scheduling document processing, summaries or repository maintenance should inspect recipes with overrides, update through their normal change process and verify the effective configuration. This 30 October report uses release notes and maintainer changes. Friday Works captured the actual 1.57.0 CLI and validated a sample recipe, but did not execute a scheduled model call.

Which settings need comparison?

Change 13138 shares recipe-settings resolution between Desktop and the scheduler. The fields include goose_provider, goose_model, temperature and max_turns: provider, model, generation behavior and maximum turns.

Temperature support and meaning depend on the model. A turn limit is not a strict monetary cap because different turns can consume different amounts of work. Retain provider budgets and tool restrictions where appropriate.

The change also aligns Desktop temperature handling with the CLI according to the maintainer. It does not establish that all differences between Desktop, CLI and background execution have disappeared.

Why behavior may change after the update

A recipe specifying model A may previously have used model B from global configuration. Applying the intended override can therefore change behavior after an upgrade. Record both intended and observed settings before treating a changed output as a model regression.

For a scheduled daily report, use harmless sample documents to check provider, model, limits and output. A successful scheduler notification alone is insufficient. Friday Works recommends reviewing important recipes, preserving previous configuration and testing in isolation before changing production schedules.

Desktop extension policies are tightened separately

Version 1.57.0 also hardens the Desktop extension-allowlist fetcher. When configured, its source and redirects must use HTTPS, and fetch, redirect or parsing failures fail closed instead of silently opening access.

A configured empty list denies every extension; an absent policy does not automatically become a deny-all policy. Administrators should test valid and failing policy sources separately. Friday Works did not test Desktop enforcement during the CLI capture; this section reports release and change 12619 evidence.

What a useful small test should retain

The screenshots show CLI 1.57.0, schedule help, the sample recipe and a successful recipe validation. The fixture uses an unconnected model name and no customer information; the schedule list is empty. No schedule was created.

A deployment evaluation needs an additional authorized execution with fixed input, effective-setting evidence and an output check. Syntax validation proves readability, not model execution or report quality. The release matters because consistent configuration enables auditable automation; operational adoption still requires reproducible work, bounded permissions and evidence from the organization's own environment.

Further implementation reading

Friday Works provides implementation information and evaluation steps for business systems.