feat: add `oci switch` subcommand for named profile switching

Summary

OCI CLI supports named profiles via --profile and OCI_CLI_PROFILE, but has no built-in mechanism to list, switch between, or manage multiple profiles interactively. This is a notable UX gap compared to tools like kubectl (config use-context) and awsume/aws-vault for AWS.

Problem

Users managing multiple tenancies (a common pattern in MSP/enterprise environments) must manually track profile names and either pass --profile on every command or hand-edit OCI_CLI_PROFILE exports. There is no:

• oci switch list to enumerate available profiles
• oci switch <name> to activate a profile for the session
• Configurable discovery pattern to load profiles from split config files (e.g. ~/.oci/config_<tenancy>)

Proposed Solution

Add an oci switch subcommand with three capabilities:

1. Configure a discovery prefix

oci switch --configure
> Config file prefix pattern [config_]: config_
> Config directory [~/.oci]: ~/.oci

Stored in ~/.oci/oci_cli_rc under [OCI_CLI_SETTINGS].

2. List available profiles

$ oci switch list
Available profiles (prefix: config_):
  prod          (~/.oci/config_prod)
  staging       (~/.oci/config_staging)
  dev           (~/.oci/config_dev)
  dr            (~/.oci/config_dr)

Discovers files matching the configured prefix pattern in ~/.oci/.

3. Activate a profile

$ oci switch prod
Switched to profile: prod
  Config file : ~/.oci/config_prod
  Profile key : config_prod
  Region      : me-jeddah-1

Export for current shell:
  export OCI_CONFIG_FILE=~/.oci/config_prod
  export OCI_CLI_PROFILE=config_prod

Since CLI subprocesses cannot mutate the parent shell environment, the switch command prints the export block. A shell function wrapper (installable via oci switch --install-shell-integration) handles the eval automatically:

# Added to ~/.zshrc or ~/.bashrc by --install-shell-integration
ociswitch() { eval "$(oci switch "$@" --shell-eval)"; }

Config File Format (split profile pattern)

The current convention of a single ~/.oci/config with multiple [PROFILE] blocks does not scale well across many tenancies. A split-file pattern is common in practice:

~/.oci/
  config_prod
  config_staging
  config_dev
  config_dr

Each file contains a single [config_<name>] stanza. oci switch should support both the standard single-file multi-profile format and this split-file pattern, controlled by the configured prefix.

Reference Implementation

A shell-function prototype demonstrating the core logic:

ocswitch() {
  local oci_dir="${HOME}/.oci"
  if [[ -z "$1" ]]; then
    echo "Available profiles:"
    ls "$oci_dir"/config_* 2>/dev/null | sed "s|$oci_dir/config_||"
    return 0
  fi
  local cfg="$oci_dir/config_$1"
  [[ ! -f "$cfg" ]] && { echo "Error: profile '$1' not found" >&2; return 1; }
  export OCI_CONFIG_FILE="$cfg"
  export OCI_CLI_PROFILE="config_$1"
  echo "Switched to OCI profile: $1"
}

This works but requires manual shell sourcing and has no discovery configuration or shell integration. A native oci switch would make this a first-class CLI capability.

Scope

• New switch command group in the CLI
• list, configure, shell integration (--install-shell-integration, --shell-eval)
• Backward-compatible: no changes to existing profile resolution order
• Works with both single ~/.oci/config and split config_<name> file layouts

Willingness to Contribute

I'm actively using OCI CLI across a multi-tenancy OCI estate and have the context to build this well. I've previously contributed to oracle/oci-native-ingress-controller#139. Happy to take this on if the maintainers are open to the direction — please assign me.

No files or tests are named. Start by tracing the existing CLI command registration and profile resolution paths, then review how configuration and shell integration are handled. Done means a backward-compatible switch command supports listing, configuring, and activating both standard and split profile layouts, with the requested shell-evaluation behavior.