just-vibeVite · inspect by default
/vite-env
Check environment loading and exposure of server-only values
Use for build mode, environment loading and client exposure; vercel-env checks deployment scope metadata and security-secrets searches the repository and history for committed credentials.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select vite-env from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv vite-env, /just-vibe vite-env and /jv:vite-env in Claude. See shortcut setup and context examples.
/just-vibe:vite-env Check whether server-only configuration is exposed in the client bundle./just-vibe:vite-env Diagnose a staging build made with a production NODE_ENV and a custom mode./just-vibe:vite-env Inspect environment references without reading secret values or building output.What the agent does
- Trace import.meta.env usage and the configured envPrefix, and inspect mode-specific files by names only.
- Determine which mode supplies each name, separating build mode from NODE_ENV, and inspect existing generated bundles for exposure when available.
- Recommend narrow corrections.
Inputs
- build mode, expected variable names, environment files, and exposure policy.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Load precedence, prefixes, build-time replacement, and client/server separation.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Inspect; build mode, expected variable names, environment files, and exposure policy. Apply for a requested configuration fix without reading or printing secret values.
- Prerequisites
- Project manifests, lockfile, Vite/framework/plugin versions, and existing build scripts. Verify current version-specific documentation when changing configuration. Requested isolated verification may generate disposable build/cache artifacts; inspect their scripts first and preserve product files.
Expected output
- Redacted name/consumer/mode/exposure table with exposure and missing-value findings, and evidence from a controlled built artifact.
How the work is checked
- Server-only credentials are not moved into client-exposed prefixes; development and production modes resolve the intended public configuration.
When to stop or clarify
- Never print secret values. Secret rotation is a separate authorized action; configuration edits use apply mode.
Handling missing context
- Infer
- Read manifests, lockfile, installed Vite/plugins, entry points, aliases, modes and current build scripts.
- Assume
- Preserve existing tooling and base-path conventions; in apply mode, make a local focused change when the brief identifies the behavior, and otherwise propose it.
- Ask
- Ask if the intended serving subpath or deployment target cannot be inferred and would change generated URLs; do not ask for versions present in the lockfile.
Technical guidance
- Evidence
- Inspect modes, envDir, public prefixes, define substitutions and client import paths using variable names.
- Method
- Trace whether the value is compiled into client output or read only by server code; keep mode distinct from NODE_ENV.
- Pitfall
- Prefixing a secret with VITE_ makes it public; booleans read from env may be strings with surprising truthiness.
- Check
- Build with a synthetic sentinel and inspect intended exposure and parsing without placing real secret values in reports.
Situational decisions
When a required secret is referenced by client code: Move the privileged operation behind a server boundary instead of adding a client-exposed prefix.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.