Refactor pc config to support key-based configuration and commands

[austin-denoble]

Problem

The pc config command exposed configuration through a flat set of verb-noun subcommands — get-api-key, set-api-key, set-color, set-environment — with one Cobra command file per setting. The pattern had a few problems:

• Adding a new setting required adding a new command file and registering it in two places (the config command tree and the root-level auth-skip list).
• No way to view all current settings at once — no list equivalent.
• No way to describe a setting (its purpose, valid values, sensitivity).
• The naming diverged from how most modern CLIs (gh, aws, npm, stripe) handle config, raising the learning curve for new users.

This becomes more painful as the set of configurable values grows.

Solution

Refactor pc config to a generic, registry-driven interface modeled after gh config. A single keyDescriptor in internal/pkg/cli/command/config/registry.go holds each setting's getter, setter, clear function, optional onChange side-effect hook, short and long descriptions, sensitivity flag, and valid values. The get / set / unset / list / describe commands are generic and dispatch through the registry — adding a new config key is now a single registry entry, no new command file required.

New commands

$ pc config list
KEY           VALUE        DESCRIPTION
api-key       <not set>    Default API key for authenticating with Pinecone
environment   production   Pinecone environment to target (production or staging)
color         true         Enable or disable colored terminal output

$ pc config get api-key
[INFO] api-key: <not set>

$ pc config set api-key pcsk_...
[SUCCESS] api-key updated

$ pc config set environment staging
[SUCCESS] environment updated
[INFO] You have been logged out; to login again, run `pc login`
[INFO] To set a new API key, run `pc config set api-key <value>`

$ pc config unset api-key
[SUCCESS] api-key cleared

$ pc config describe environment
KEY            environment
VALUE          production
SENSITIVE      false
VALID VALUES   production, staging
DESCRIPTION    Pinecone environment to target (production or staging)

Select which Pinecone environment the CLI talks to. Most users should leave this set to 'production'; 'staging' is intended for Pinecone internal development.

Changing the environment clears your existing authentication state: any OAuth session is logged out, the default API key is cleared, and the target organization and project are reset. You will need to re-authenticate
and re-target after switching.

Registry-driven extensibility

Each setting is one entry in configRegistry. Adding a new key — say, a default output format — would look like:

"output-format": {
    Description: "Default output format for commands",
    ValidValues: []string{"text", "json"},
    getStr: func() string { return conf.OutputFormat.Get() },
    setStr: func(value string) error {
        switch value {
        case "text", "json":
            conf.OutputFormat.Set(value)
            return nil
        default:
            return fmt.Errorf("invalid value %q; must be one of: text, json", value)
        }
    },
    clearStr: func() { conf.OutputFormat.Clear() },
},

No new command file. No changes to root.go's skip-auth list. It just works across get, set, unset, list, and describe.

Side-effect hooks

The environment key needs to clear OAuth state, the API key, and the target org/project when it changes. That used to live inline in set-environment. It now lives in an onChange hook on the registry entry and fires consistently from both set and unset:

onChange: func(ctx context.Context, _, _ string) []string {
    // Logout OAuth, clear API key, clear target org/project,
    // return human-readable info lines for the user.
}

Flags

• --json on get, list, describe for machine-readable output.
• --reveal on get, list, describe to unmask sensitive values (defaults to masking head/tail for api-key).

Backwards compatibility

The four legacy commands (get-api-key, set-api-key, set-color, set-environment) are preserved as hidden, deprecated aliases. They continue to function and print Cobra's standard deprecation notice
pointing at the new equivalent:

$ pc config set-color true
Command "set-color" is deprecated, use 'pc config set color <true|false>' instead
[SUCCESS] Config property color updated to true

Existing scripts and docs keep working; new users land on the new pattern.

Type of Change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

The legacy commands are kept as hidden aliases, so this is non-breaking for existing users. Docs referencing pc config set-api-key etc. should be updated to use pc config set api-key <value> going forward.

Test Plan

• just test-unit passes
• pc config list — confirms all three keys render with descriptions
• pc config get api-key — confirms <not set> placeholder for empty values
• pc config get api-key --reveal — confirms full value shown when revealed
• pc config set environment staging — confirms OAuth/API key/target wipe fires
• pc config unset environment (from staging) — confirms same wipe fires (regression fix)
• pc config set environment prod — confirms canonical "production" is stored and reported
• pc config describe api-key / environment / color — confirms long description rendered when present, omitted when blank
• Legacy pc config get-api-key / set-api-key / set-color / set-environment — confirms each still works and prints deprecation notice
• --json on get, list, describe — confirms structured output

---

Note

Medium Risk
Changes how API keys and environment are written and can clear OAuth, targets, and auth context; legacy commands still behave differently for API key auth until users migrate.

Overview
pc config is reworked around a central configRegistry so one get / set / unset / list / describe flow covers all keys (api-key, color, environment) instead of separate subcommands per setting. New commands support --json and --reveal for sensitive values; list and describe expose descriptions, valid values, and long help text.

Registry entries drive validation, persistence, and onChange side effects (e.g. environment logs out OAuth, clears API key and target org/project—now on set and unset). api-key set/unset reconciles AuthContext via the registry; the old set-api-key path did not. ConfigProperty.GetStored() compares file-only values so env overrides do not block no-op detection.

Legacy get-api-key, set-api-key, set-color, and set-environment remain as hidden, deprecated aliases. Root skip-auth lists the five new config subcommands. Minor copy fix in auth configure help (“API key”).

^{Reviewed by Cursor Bugbot for commit 4759118. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 4 potential issues.

There are 7 total unresolved issues (including 3 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4759118. Configure here.}

[cursor]

Set output ignores stored config

Medium Severity

runSetCmd treats ConfigService.Get as the persisted value for --json success output and for ErrNoChange messaging, but Get returns effective values (including PINECONE_* env overrides). Environment no-op detection uses GetStored, so users can see the wrong value—or a value that contradicts what they just set—when overrides are in play.

Additional Locations (1)

• internal/pkg/cli/command/config/registry.go#L146-L158

 

^{Reviewed by Cursor Bugbot for commit 4759118. Configure here.}

[cursor]

Api-key unset ignores file value

Medium Severity

The new Unset path uses getStoredStr for environment so env overrides do not trigger a no-op incorrectly, but api-key has no getStoredStr and still compares secrets.DefaultAPIKey.Get() (which honors PINECONE_* env vars). pc config unset api-key can run onChange, report success, and rewrite auth context even when the secrets file is already empty and only an env var supplies the key.

Additional Locations (1)

• internal/pkg/cli/command/config/registry.go#L300-L310

 

^{Reviewed by Cursor Bugbot for commit 4759118. Configure here.}

[cursor]

Color set rejects one alias

Low Severity

The registry color validator accepts true, false, on, and off, but not 1, while the deprecated hidden set-color command still treats 1 as enabled. Users moving to pc config set color 1 get a validation error instead of the behavior the legacy alias still provides.

Additional Locations (1)

• internal/pkg/cli/command/config/set_color.go#L31-L36

 

^{Reviewed by Cursor Bugbot for commit 4759118. Configure here.}

[cursor]

OAuth may survive environment switch

Medium Severity

The environment onChange hook decides whether to call oauth.Logout() from the result of oauth.Token, but it discards that function’s error. oauth.Token can return an error while refresh or claim parsing fails even though OAuth tokens are still stored locally, so the hook skips Logout, continues the environment change, and leaves the previous session on disk.

 

^{Reviewed by Cursor Bugbot for commit 4759118. Configure here.}