chore(deps): update dependency wrangler to v4.95.0 - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
wrangler (source)	4.93.1 → 4.95.0

---

Release Notes

cloudflare/workers-sdk (wrangler)

v4.95.0

Minor Changes

• #​14009 ca5b604 Thanks @​dario-piotrowicz! - Add telemetry for detecting whether AI coding agents have Cloudflare skills installed

  Wrangler now includes a currentAgentSkillsInstalled property in telemetry events that reports whether the current AI coding agent has Cloudflare skills present on disk. The value distinguishes between skills installed automatically by Wrangler ("automatic"), skills installed manually by the user ("manual"), no skills present (false), or no supported agent detected (null). Skill names are fetched from the GitHub Contents API with a 24-hour disk cache to avoid rate limits.

• #​14014 d042705 Thanks @​emily-shen! - Add --x-deploy-helpers to gate an upcoming deploy path refactor.

Patch Changes

• #​14003 c1fd2fd Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260521.1	1.20260526.1

• #​13728 49c1a59 Thanks @​penalosa! - Reject remote: false on always-remote bindings (AI, AI Search, Media, Artifacts, Flagship, VPC Service, VPC Network)

  These binding types have no local simulator and the resource is fundamentally remote-only. Setting remote: false was previously silently accepted but produced a non-functional binding. wrangler dev now fails with a clear error directing users to either remove the remote field or set it to true.

• #​14039 fee1ce4 Thanks @​dario-piotrowicz! - Preserve --compatibility-flags in the interactive deploy config flow

  When running wrangler deploy without a config file and going through the interactive setup flow, any --compatibility-flags passed on the command line (e.g. --compatibility-flags=nodejs_compat) were lost in two places:

  1. The generated wrangler.jsonc file did not include compatibility_flags.
  2. The suggested CLI command shown when declining the config file write did not include --compatibility-flags.

  Both are now fixed. Compatibility flags are persisted to the generated config and included in the suggested command.

• #​14010 b3962ff Thanks @​dario-piotrowicz! - Improve error messages for Pages CLI commands

  Error messages across wrangler pages subcommands (deploy, dev, secret, project, etc.) now provide clearer descriptions and actionable guidance. For example, instead of "Must specify a project name.", you'll now see "Missing Pages project name. Use --project-name or set the name in your wrangler.jsonc configuration file."

• #​14011 420e457 Thanks @​petebacondarwin! - Warn when a remote-bindings request is blocked by Cloudflare Access

  When wrangler dev is used with remote bindings and a request from the local remote-bindings proxy client to the remote workers.dev proxy server is blocked by Cloudflare Access (HTTP 403 with the Cloudflare Access block page), Wrangler now:

  • Logs a single, visually striking warning per dev session explaining how to set CLOUDFLARE_ACCESS_CLIENT_ID / CLOUDFLARE_ACCESS_CLIENT_SECRET (Service Token credentials) or run cloudflared access login to authenticate.
  • Replaces the original Access HTML block page with a readable plain-text body containing the same guidance, so the message also reaches the user via binding error messages (e.g. InferenceUpstreamError from env.AI.run()) and any browser response piped back via a service binding .fetch().

  Previously the 403 was returned to user code with the full Access HTML, which both drowned out other logs and made it hard to tell that the failure was due to Cloudflare Access on workers.dev rather than a problem in the binding itself or the deployed proxy server. The detection runs inside the proxy client worker (which only ever talks to the remote-bindings proxy URL), so it does not trigger false positives on user-worker 403s.

• #​14044 8b1467e Thanks @​pombosilva! - Rename Workflow binding schedule property to schedules

  The schedule property on Workflow bindings introduced in #​13467 has been renamed to schedules to match the control plane API.

  Note: This remains a configuration-only change. Scheduled triggering of Workflow instances is not yet available — adding schedules to a Workflow binding will not result in scheduled invocations at this time.

• Updated dependencies [c1fd2fd, 420e457]:

  • miniflare@​4.20260526.0

v4.94.0

Compare Source

Minor Changes

• #​13897 52e9082 Thanks @​dario-piotrowicz! - Add automatic Cloudflare skills installation for AI coding agents

  Wrangler now detects AI coding agents and offers to install Cloudflare skill files from the cloudflare/skills GitHub repository. Users are prompted once interactively; subsequent runs skip the prompt. Use --install-skills to install without prompting.

• #​13989 f598eac Thanks @​MattieTK! - Print a QR code alongside the tunnel URL when sharing via Cloudflare Tunnel

  When a tunnel is started (via wrangler dev --tunnel or the Vite plugin with tunnel: true), a scannable QR code is now printed to the terminal beneath the tunnel URL. This makes it easy to open the tunnel on a mobile device without manually copying the URL.

  The QR code uses Unicode block characters for a compact representation and is generated best-effort -- if generation fails for any reason, the tunnel URL is still displayed as before.

• #​13467 3a1fbed Thanks @​deloreyj! - Add schedule property to Workflow bindings for cron-based triggering

  Note: This is a configuration-only change. Scheduled triggering of Workflow instances is not yet available — adding schedule to a Workflow binding will not result in scheduled invocations at this time. This change lays the groundwork for an upcoming feature.

  Workflow bindings in wrangler.json now accept an optional schedule field that configures one or more cron expressions to automatically trigger new workflow instances on a schedule.

  // wrangler.json
  {
    "workflows": [
      {
        "binding": "MY_WORKFLOW",
        "name": "my-workflow",
        "class_name": "MyWorkflow",
        "schedule": "0 9 * * 1"
      }
    ]
  }

  Multiple schedules can be provided as an array:

  {
    "workflows": [
      {
        "binding": "MY_WORKFLOW",
        "name": "my-workflow",
        "class_name": "MyWorkflow",
        "schedule": ["0 9 * * 1", "0 17 * * 5"]
      }
    ]
  }

  The schedule is sent to the Workflows control plane on wrangler deploy. Configuring schedule on a workflow binding that references an external script_name is an error — the schedule must be configured on the worker that defines the workflow.

Patch Changes

• #​13993 0733688 Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260520.1	1.20260521.1

• #​14008 fc1f7b9 Thanks @​petebacondarwin! - Fix Access Service Token authentication for applications that only allow service tokens

  When using remote bindings against a Worker behind a Cloudflare Access application configured to only allow Service Auth tokens (no interactive user authentication), Wrangler previously ignored the CLOUDFLARE_ACCESS_CLIENT_ID and CLOUDFLARE_ACCESS_CLIENT_SECRET environment variables and the request would fail with a 403.

  This happened because Wrangler detects Access by looking for a 302 redirect to cloudflareaccess.com. A service-auth-only Access application has no interactive login path, so it responds with a hard 403 instead of redirecting. Wrangler concluded the domain was not behind Access and skipped attaching the service token headers entirely.

  The env-var check now runs before the Access detection step, so the configured service token credentials are always used when present.

• #​12277 8c569c6 Thanks @​penalosa! - Include column names in D1 SQL export INSERT statements

  D1 SQL exports now include column names in INSERT statements (e.g., INSERT INTO "table" ("col1","col2") VALUES(...)). This ensures that exported SQL can be successfully imported even when the target table has columns in a different order than the original, which commonly occurs during iterative development when schemas evolve.

• Updated dependencies [0733688, 30657e1]:

  • miniflare@​4.20260521.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.