bug: @cloudflare/vite-plugin ignores active wrangler auth profiles and defaults to default.toml

[daviddecorso]

What versions & operating system are you using?

• OS: macOS / Linux
• Wrangler version: ^4.107.0 (or matching latest)
• @cloudflare/vite-plugin version: ^1.13.8 (or matching latest)

Please provide a link to a minimal reproduction

https://github.com/daviddecorso/wrangler-auth-vite-bug-repro

Describe the Bug

When using @cloudflare/vite-plugin for local development (vite dev), the plugin does not respect the active authentication profile set via wrangler auth. Instead, it defaults to the OAuth credentials stored in default.toml (e.g. at ~/Library/Preferences/.wrangler/config/default.toml on macOS).

In contrast, running wrangler dev in the same directory correctly respects the directory-activated profile (configured via wrangler auth activate <profile>).

Reproduction Steps

1. Create a custom Wrangler authentication profile:

   wrangler auth create my-custom-profile

2. Activate the profile in your project directory:

   wrangler auth activate my-custom-profile

3. Run wrangler dev and verify that it correctly uses the credentials and account associated with my-custom-profile.
4. Configure @cloudflare/vite-plugin in your vite.config.ts:

   import { cloudflare } from '@cloudflare/vite-plugin';
   import { defineConfig } from 'vite';
   
   export default defineConfig({
       plugins: [
           cloudflare({ viteEnvironment: { name: 'ssr' } })
       ]
   });

5. Run your dev server via Vite:

   vite dev

6. Observe that any calls to remote bindings (such as D1, KV, or Workers AI) authenticate using the global default profile token from ~/.wrangler/config/default.toml (or macOS equivalent ~/Library/Preferences/.wrangler/config/default.toml) instead of my-custom-profile.

Expected Behavior

vite dev (running @cloudflare/vite-plugin) should resolve the active Wrangler authentication profile in the same order as the Wrangler CLI:

1. Environment variables (CLOUDFLARE_API_TOKEN etc.)
2. --profile flag (if configurable)
3. The directory-activated profile (using the nearest ancestor directory activated via wrangler auth activate)
4. Global default profile (default.toml)

Actual Behavior

The plugin seems to bypass directory-activated auth profiles entirely and directly reads/uses the OAuth token from the global default configuration file (default.toml).

Additional Information / Possible Cause

Because @cloudflare/vite-plugin runs inside Vite's Node process and programmatically spawns Miniflare/workerd or imports wrangler modules, it likely does not pass the current working directory (CWD) or context required by the wrangler auth module to resolve directory-activated profiles. As a result, Wrangler's internal auth resolver defaults to default.toml.

Confirmed via Local Reproduction

This has been reproduced in this minimal repo.

Verification method

A surface-level check (e.g. "does the AI binding call succeed?") is not sufficient to detect this bug if the default-profile account also happens to have access to the same resource since the call can succeed while silently using the wrong account. The reliable way to confirm which credentials are actually used is to diff the Cloudflare API account ID hit by each command:

# Terminal 1 — CLI, for comparison
WRANGLER_LOG=debug wrangler dev

# Terminal 2 — via the Vite plugin
WRANGLER_LOG=debug pnpm dev

Then grep each command's output for outbound Cloudflare API calls:

grep "accounts/" <log file>
# e.g. -- START CF API REQUEST: GET https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/workers/subdomain

Result

With two profiles configured (a directory-activated non-default profile, and the global default profile, each associated with a different Cloudflare account):

Command	Profile used	Account hit
wrangler dev	directory-activated profile (correct)	account tied to the activated profile
vite dev via @cloudflare/vite-plugin	default profile (incorrect)	account tied to default.toml, regardless of directory activation

Please provide any relevant error logs

No response