Skip to content

Add envs to ldcli config, replacing flags-usage's static env fallback#743

Draft
davidbrackbill wants to merge 1 commit into
db/flagpls-usagefrom
db/flagpls-envs
Draft

Add envs to ldcli config, replacing flags-usage's static env fallback#743
davidbrackbill wants to merge 1 commit into
db/flagpls-usagefrom
db/flagpls-envs

Conversation

@davidbrackbill

@davidbrackbill davidbrackbill commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds envs as a real ldcli config field (Config.Envs, cliflags.EnvsFlag), following the exact pattern already used for project/environment/access-token: settable via ldcli config --set envs=a,b,c, resolved through the standard flag → LD_ENVS env var → config file precedence via viper.BindPFlag (the --envs flag on flags usage wasn't wired through viper before this).
  • When none of flag/env/config set anything, flags usage now falls back to live-discovering the project's critical environments via the LD API (ported from flagpls's setup wizard) instead of a hardcoded generic env list — the hardcoded list didn't match most projects' real critical envs, which caused blank tables when omitting -envs (matching flagpls's own default behavior, used by its nvim/vscode plugin integrations).

Stacked on top of #742.

Test plan

  • go build ./... and go test ./... pass (including a golden-file update for ldcli config --help)
  • Zero-config: same command shape the nvim/vscode plugins use (omitting -envs) now live-discovers critical envs instead of returning a blank table
  • ldcli config --set envs=... persists as a real YAML list, and is picked up by flags usage
  • ldcli config --unset envs cleans up correctly

Claude claude@anthropic.com


Note

Medium Risk
Changes default behavior for flags usage when --envs is omitted (now an API call and different env set), and adds outbound REST calls using the user's access token.

Overview
Adds a first-class envs config key (persisted as a YAML list via ldcli config --set envs=a,b,c) and wires flags usage to resolve environments through --envsLD_ENVS → config via viper, replacing the local-only --envs string flag.

When nothing is configured, flags usage now auto-discovers the project’s critical environments by calling the LaunchDarkly REST API (fetchCriticalEnvs) instead of relying on a static default—so editor/plugin flows that omit --envs get meaningful per-env columns. Discovery failures emit a warning and the command can continue with an empty env list.

Config help/golden text is updated to document envs.

Reviewed by Cursor Bugbot for commit 82aa923. Bugbot is set up for automated code reviews on this repo. Configure here.

Adds `envs` as a real config field (Config.Envs, cliflags.EnvsFlag),
following the exact pattern already used for project/environment/
access-token: settable via `ldcli config --set envs=a,b,c`, and resolved
through the standard flag -> LD_ENVS env var -> config file precedence
via viper.BindPFlag (the --envs flag on `flags usage` wasn't wired
through viper before this).

When none of flag/env/config set anything, `flags usage` now falls back
to live-discovering the project's critical environments via the LD API
(ported from flagpls's `setup` wizard) instead of a hardcoded generic
env list — the hardcoded list didn't match most projects' real critical
envs, which is what caused the nvim/vscode plugin swap to render blank
tables when they omit -envs (matching flagpls's own default behavior).

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 82aa923. Configure here.

Comment thread cmd/flags/usage.go
fmt.Fprintf(cmd.ErrOrStderr(), "warning: couldn't auto-discover critical environments (%v); pass --envs explicitly\n", err)
}
envs = discovered
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Silent default env resolution change

Medium Severity

Omitting --envs now live-discovers critical environments via the API instead of relying on the prior implicit DefaultCriticalEnvs behavior, changing which environments appear in flags usage output. The command only prints a stderr notice when discovery fails, not when the default resolution path changes on success.

Fix in Cursor Fix in Web

Triggered by learned rule: Breaking CLI default changes require transitional stderr warnings

Reviewed by Cursor Bugbot for commit 82aa923. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant