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

[cursor]

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

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

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