agents · review · first seen Oct 29, 09:32 UTC

Goose tightens allowlist checks in v1.57.0

Goose v1.57.0 shipped HTTPS and redirect checks for its allowlist, and blocks when an allowlist policy fails. A builder using an allowlist should check whether existing workflows still pass the policy before relying on this version.

L0 · primary1 source4 claims checked4 min read

What shipped

The v1.57.0 release notes say the allowlist requires HTTPS. That is a shipped requirement, not a proposed setting. The excerpt does not spell out which allowlist entries, requests, or configuration paths encounter the check. Treat the release note as a reason to inspect the allowlist configurations you actually use, rather than as a complete description of every affected path. [1]

The same release entry says Goose validates redirects for the allowlist and blocks on policy failure. Those are distinct points: a redirect is checked, and a policy failure blocks the operation. The notes do not say which redirect patterns pass, how many redirects are followed, or what a caller sees when blocking occurs. A test should therefore cover both an allowed path and a path expected to fail. [1][2]

A separate v1.57.0 feature lets callers supply Goose session IDs. The release excerpt lists it alongside the allowlist work, but does not connect the two features. Do not assume that supplying a session ID changes allowlist enforcement. If your integration supplies session IDs, test that path as its own change while assessing the allowlist behavior independently. [1][2][3][4]

Why it matters if you build

For a builder with an allowlist policy, the immediate question is whether the configuration still permits the work it is meant to permit. The HTTPS requirement can matter to entries that do not meet it, while redirect validation adds another point at which a path may be checked. The release notes establish the checks, not the result for any particular configuration. Review your own entries and exercise the paths your workflow depends on before deciding that the change is harmless. [1][2]

Blocking on policy failure makes a failed check an operational outcome, not merely a finding to note later. A workflow that depends on a path should be tested for both successful passage and a deliberate policy failure. The excerpt does not specify the error text, recovery procedure, or whether a previously working workflow will fail. Those costs have to be measured in your setup rather than inferred from the release line. [1][2]

Caller-supplied session IDs may matter if your integration already manages which Goose session it uses. The release note confirms the capability but gives no contract for ID format, reuse, or conflicts. Keep that assessment separate from the allowlist decision: neither feature is evidence that the other is required. If session handling is not part of today's work, it need not determine whether you test the policy changes. [1][2][3][4]

How to try it today

1. Review the allowlist policy you use for entries that may not meet the HTTPS requirement.
2. Run a permitted path under that policy and record whether it completes.
3. Run a path involving a redirect and check its result against your intended policy.
4. Run a path intended to fail the policy and check that the operation is blocked.
5. If your caller supplies Goose session IDs, exercise that path separately from the allowlist tests.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Goose v1.57.0 requires HTTPS for its allowlist.

   per GitHub releases · block/goose (L0)
2. shipped L0 · primary

   Goose v1.57.0 validates redirects for its allowlist.

   per GitHub releases · block/goose (L0)
3. shipped L0 · primary

   Goose v1.57.0 blocks on allowlist policy failure.

   per GitHub releases · block/goose (L0)
4. shipped L0 · primary

   Goose v1.57.0 allows callers to supply Goose session IDs.

   per GitHub releases · block/goose (L0)

What is not confirmed

The release excerpt does not define the scope of the HTTPS requirement, the redirect rules, or the form of a policy-failure response. It does not establish which existing allowlist configurations will need changes. Do not turn the short feature line into a compatibility guarantee or a prediction of failure for a specific workflow. [1][2][3]

The excerpt does not give the format or lifecycle rules for caller-supplied Goose session IDs. It also does not say that supplying an ID affects allowlist checks. Those details remain unconfirmed by the supplied material. [1][2][3][4]

Who should act, who should wait

Move now if an allowlist policy governs a workflow you need today. Review its HTTPS entries, exercise redirects, and verify that a policy failure blocks as intended before treating v1.57.0 as ready for that workflow. The shipped checks are enough to justify targeted testing; they are not enough to declare every configuration compatible. [1][2][3]

Wait on changing unrelated integrations solely because this release mentions caller-supplied session IDs. If you need that capability, test it, but the excerpt supplies no usage contract and no basis for tying it to the allowlist change. Builders without an allowlist-dependent workflow can defer the policy review until they have a configuration to assess. [1][2][3][4]

Sources

• v1.57.0 — GitHub releases · block/goose L0 · primary