Dev server blocks Gitpod/cloud environment preview URLs - allowedHosts configuration ignored

[localgod]

Sanity Studio Dev Server Blocks Gitpod Preview URLs with Host Validation Error

Describe the bug

When running sanity dev in a Gitpod workspace, the Vite dev server blocks all requests from Gitpod's preview URLs with the error:

Blocked request. This host ("3333--0199e902-1fdc-7086-8a35-dd1bec1b6044.eu-central-1-01.gitpod.dev") is not allowed.
To allow this host, add "3333--0199e902-1fdc-7086-8a35-dd1bec1b6044.eu-central-1-01.gitpod.dev" to `server.allowedHosts` in vite.config.js.

The issue is that Sanity Studio appears to generate its own Vite configuration that ignores user-provided allowedHosts settings, making it impossible to run the studio in cloud development environments like Gitpod, GitHub Codespaces, or similar platforms.

To Reproduce

Steps to reproduce the behavior:

1. Create a Sanity Studio project (or use an existing one)
2. Open the project in a Gitpod workspace: https://gitpod.io/#<your-repo-url>
3. Run npm run dev -- --host=0.0.0.0 (or sanity dev --host=0.0.0.0)
4. Access the preview URL provided by Gitpod (e.g., https://3333--<workspace-id>.gitpod.dev)
5. See the "Blocked request" error in the browser

Attempted Solutions (None Worked)

1. Creating vite.config.ts with allowedHosts:

import {defineConfig} from 'vite'

export default defineConfig({
  server: {
    host: '0.0.0.0',
    allowedHosts: true, // or ['.gitpod.dev']
  },
})

2. Adding vite config to sanity.config.ts:

export default defineConfig({
  // ... other config
  vite: {
    server: {
      host: '0.0.0.0',
      allowedHosts: true,
    },
  },
})

3. Using vite config as a function in sanity.config.ts:

export default defineConfig({
  // ... other config
  vite: (prevConfig) => ({
    ...prevConfig,
    server: {
      ...prevConfig.server,
      host: '0.0.0.0',
      allowedHosts: true,
    },
  }),
})

4. Using environment variable (as per Vite docs):

__VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS=".gitpod.dev" npm run dev -- --host=0.0.0.0

5. Creating custom Vite plugin to bypass host check:

vite: (prevConfig) => ({
  ...prevConfig,
  plugins: [
    ...(prevConfig.plugins || []),
    {
      name: 'allow-all-hosts',
      configureServer(server) {
        server.middlewares.use((req, res, next) => {
          next()
        })
      },
    },
  ],
})

None of these approaches work, suggesting that Sanity's CLI generates runtime Vite configuration that overrides user settings for the allowedHosts option.

Expected behavior

The Sanity Studio dev server should respect user-provided Vite configuration for allowedHosts, either through:

1. vite.config.ts / vite.config.js files
2. The vite option in sanity.config.ts
3. Environment variables like __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS

Alternatively, Sanity could provide its own configuration option for allowed hosts, such as:

export default defineConfig({
  server: {
    allowedHosts: ['.gitpod.dev', '.github.dev'],
  },
})

Screenshots

Error displayed in browser:

Blocked request. This host ("3333--0199e902-1fdc-7086-8a35-dd1bec1b6044.eu-central-1-01.gitpod.dev") is not allowed.
To allow this host, add "3333--0199e902-1fdc-7086-8a35-dd1bec1b6044.eu-central-1-01.gitpod.dev" to `server.allowedHosts` in vite.config.js.

Server logs show successful startup:

✓ Checking configuration files...
- Starting dev server
✓ Starting dev server
Sanity Studio using vite@7.1.7 ready in 357ms and running at http://0.0.0.0:3333/

Which versions of Sanity are you using?

@sanity/cli (global)          4.10.3 (up to date)
@sanity/eslint-config-studio   5.0.2 (up to date)
@sanity/vision                4.10.3 (up to date)
sanity                        4.10.3 (up to date)

What operating system are you using?

Linux (Gitpod workspace)

Linux ip-172-31-12-22 6.14.10-gitpod sanity-io/sanity#1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Which versions of Node.js / npm are you running?

npm: 10.9.3
node: v22.20.0

Additional context

Why This Matters

Cloud development environments like Gitpod, GitHub Codespaces, and Gitpod Flex are becoming increasingly popular for development workflows. These platforms use dynamic hostnames for preview URLs, which are blocked by Vite's default host validation.

While Vite provides the allowedHosts configuration option to handle this, Sanity Studio's CLI appears to override or ignore these settings, making it impossible to use Sanity Studio in these environments.

Vite Documentation Reference

According to Vite's server.allowedHosts documentation:

• Setting allowedHosts: true allows the server to respond to requests for any hosts
• Wildcard patterns like .gitpod.dev should match all subdomains
• The __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS environment variable can add additional allowed hosts

Workaround Attempts

The only current workaround would be to:

1. Use Sanity's hosted studio instead of local development
2. Set up a reverse proxy that strips/modifies the Host header (complex and not ideal)
3. Avoid cloud development environments entirely (defeats the purpose)

Suggested Solutions

1. Respect user Vite configuration: Allow vite.config.ts and the vite option in sanity.config.ts to properly configure allowedHosts

2. Add Sanity-specific configuration: Provide a dedicated option in sanity.config.ts:

   export default defineConfig({
     server: {
       allowedHosts: ['.gitpod.dev', '.github.dev', '.codespaces.dev'],
     },
   })

3. Auto-detect cloud environments: Automatically allow hosts for known cloud development platforms when detected

4. CLI flag: Add a --allow-all-hosts flag to the sanity dev command for development purposes

Related Issues

This is similar to issues faced by other frameworks when used in cloud development environments. For example:

• Next.js added support for this via experimental.allowedOrigins
• Vite itself provides the allowedHosts option specifically for this use case

Security issue?

This is not a security issue. This is a feature request/bug report about supporting legitimate cloud development environments. The request is to allow developers to explicitly configure which hosts are allowed, not to bypass security measures entirely.