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 wipe OAuth, stored API keys, and target context via centralized hooks; legacy paths still exist but behavior may diverge slightly from old inline commands.

Overview
Refactors pc config from per-setting subcommands into a registry-driven model: get, set, unset, list, and describe dispatch through configRegistry entries for api-key, color, and environment.

Each key defines validation, persistence, metadata (descriptions, sensitivity, hidden), and optional onChange hooks—e.g. api-key updates auth context like clearing the default key; environment logs out OAuth, clears the default API key, and resets org/project targets on both set and unset.

Adds ConfigProperty.GetStored() so set/unset compare against on-disk values (not env overrides), plus --json, --reveal, and list --all for hidden keys. Legacy get-api-key / set-api-key / set-color / set-environment remain as hidden deprecated aliases; new config subcommands are on the root auth-skip list. Includes broad unit tests and a small auth help typo fix (“An API key”).

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

[cursor]

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

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

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

[cursor]

Environment set skips env override

Medium Severity

pc config set environment treats a match on the value stored in the config file as no change (ErrNoChange), so it skips onChange auth resets. When PINECONE_ENVIRONMENT overrides the effective environment, the file can already be production while the CLI still targets staging, and the new path no longer runs the logout and credential clears the deprecated set-environment command did.

Additional Locations (1)

• internal/pkg/cli/command/config/set_environment.go#L43-L48

 

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