Env Development & Production Environment Variables

Based on the documentation, I can see what's happening here. The issue is that Sanity Studio's environment variable loading behavior depends on the SANITY_ACTIVE_ENV variable, which defaults to development for sanity start and production for sanity build and sanity deploy.

However, there's a known quirk: when both .env.development and .env.production files exist, the loading order can sometimes cause .env.production to take precedence or override .env.development values, depending on how your build tooling processes these files.

Here are a few solutions:

Option 1: Use SANITY_ACTIVE_ENV explicitly

When running locally, explicitly set the environment:

SANITY_ACTIVE_ENV=development sanity start

This ensures the correct environment is active.

Option 2: Use a single .env file with conditional logic

Instead of separate .env.development and .env.production files, use a single .env file and handle environment switching in your sanity.config.js:

export default defineConfig({
  projectId: process.env.SANITY_STUDIO_API_PROJECT_ID,
  dataset: process.env.SANITY_ACTIVE_ENV === 'production' 
    ? 'production-dataset' 
    : 'development-dataset',
  // other config
})

Option 3: Use .env.local for local overrides

Create a .env.local file for your local development variables. This file typically has the highest priority in most build systems and won't be used during deployment. Make sure to add it to your .gitignore.

About your sanity.json mention: If you're using sanity.json, you might be on an older version of Sanity Studio (v2). The environment variable behavior was more predictable in Studio v3+, so consider upgrading if you're still on v2.

Quick workaround: For now, you could temporarily rename .env.production to something like .env.production.backup while developing locally, then rename it back before deploying. Not elegant, but it'll unblock you.

The root cause is likely related to how your bundler (Vite in Studio v3, or webpack in Studio v2) processes multiple .env files. The SANITY_ACTIVE_ENV variable should control this, but explicit setting (Option 1) is the most reliable approach.