Add --env/--env-file flags to validate and sidecar setup

[schurchleycci]

Summary

• Adds `-e`/`--env KEY=VALUE` and `--env-file` flags to `chunk validate` and `chunk sidecar setup`, forwarding vars into the remote SSH session
• `--env-file` defaults to `.env.local` and is loaded automatically if present (silently ignored if the file doesn't exist); pass an explicit path to override
• Env vars are resolved through the secrets layer before forwarding
• Flag precedence: `--env` wins over file values
• `sidecar ssh` refactored to use the shared `resolveEnvVars` helper (was inlining equivalent logic)

Implementation notes

• `resolveEnvVars` lives in `internal/cmd/env.go` (shared by all three commands)
• For `validate`, `--env` syntax is validated eagerly so bad values are caught immediately even in dry-run/local mode; file loading and secrets resolution are deferred until a sidecar is actually in use
• `internal/testing/fakes/ssh.go` extended with `EnvVars()` to capture SSH env requests for test assertions

Test plan

• `TestOpenSSHSessionPassesEnvVars` — verifies env vars arrive over SSH
• `TestValidateEnvFlagBadValue` — `--env BADVALUE` rejected immediately, including in dry-run mode
• `TestParseEnvPairs/empty key returns error` — `=value` is rejected

🤖 Generated with Claude Code

[michael-webster]

Review Summary

Files reviewed: 7
Issues identified: 4

---

1. Silent no-op: --env flags ignored on local runs without user feedback

internal/cmd/validate.go:149 | High

When no sidecar is resolved, resolveEnvVars is skipped entirely — env vars are validated for syntax but never forwarded. A user who passes --env FOO=bar on a purely local chunk validate run gets no error and no warning; their flag silently has no effect. Consider emitting a warning via streams.ErrPrintf when len(envVarsFlag) > 0 or envFile != "" and sidecarID == "".

---

2. nil secrets delegate passed to secrets.ResolveAll without comment

internal/cmd/env.go:32 | High

secrets.ResolveAll(ctx, envVars, nil) passes nil as the resolver delegate. If ResolveAll panics or errors on a nil delegate, failures will surface only when env vars are actually present — non-deterministic in tests. The old sidecar.go inline code also passed nil, but the refactor into a shared helper amplifies the blast radius across all three commands. Is nil a documented/supported code path in secrets.ResolveAll?

---

3. sidecarSetupRunSetup: dir may be "" when resolving relative --env-file paths

internal/cmd/sidecar.go:776 | High

resolveEnvVars(cmd.Context(), dir, envFile, envVarsFlag) passes dir (the --dir flag), which is "" when not supplied. sidecar ssh explicitly calls os.Getwd() first; sidecar setup does not. With dir == "", filepath.Join("", ".env.local") resolves relative to process cwd — which may work by accident today but is inconsistent and fragile.

Suggested fix: resolve dir to os.Getwd() when empty, mirroring how sidecar ssh handles it.

---

4. SSH fake env payload parsing: missing bounds check between name and value length fields

internal/testing/fakes/ssh.go:177 | Medium

The manual SSH wire-format decoder checks int(nameLen)+8 > len(req.Payload) before reading the value length field. On a 32-bit platform, a uint32 nameLen value > math.MaxInt32 could silently overflow int, bypassing this check and causing a panic. Additionally, TestOpenSSHSessionNoEnvVars is listed in the PR test plan but is not present in validate_test.go — the no-env-vars path through openSSHSession appears untested.

[michael-webster]

What are we checking here exactly?

[michael-webster]

So the code here is fine, but I'm not really understanding the intent.

Remember, we want the user flow to be "chunk validate" and stuff just works. we do the right thing to load environment settings, create a sidecar if necessary and so on. The env overrides can be useful to debug I guess, but in terms of e.g. the hook configuration there probably won't be individual env flags.

[schurchleycci]

So the code here is fine, but I'm not really understanding the intent.

Remember, we want the user flow to be "chunk validate" and stuff just works. we do the right thing to load environment settings, create a sidecar if necessary and so on. The env overrides can be useful to debug I guess, but in terms of e.g. the hook configuration there probably won't be individual env flags.

There's a specific problem I ran into running chunk validate with web-ui-consolidated:

• node_modules isn't part of the sidecar sync because it's gitignored
• as a result, installing dependencies in the sidecar is required
• we have private dependencies, so an npm token is needed in the sidecar to install them

So in order to get a sidecar where chunk validate will work, you'd have to manually ssh into the sidecar with e.g. your NPM_TOKEN forwarded, install the dependencies, then snapshot. And even after snapshotting, if you need to refresh the dependencies in the sidecar you'd have to do the same thing.

Thinking through this again, I think there's two separate gaps:

• chunk sidecar setup may need env vars in order to run the setup steps (so adding the env forwarding to that command feels reasonable?)
• chunk sidecar sync doesn't cover refreshing stale dependencies, so the chunk sidecar sync -> chunk validate flow won't help you if dependency updates are what you're trying to test. But perhaps that's better solved by doing frequent automatic builds or something similar?

All that to say, maybe we should just pare this down to adding env forwarding to setup and leaving validate as is?