Add config.toml profiles and hoop config use-context

Description

defaultConfig always selects $HOME/.hoop/config.toml instead of resolving HOOP_CONFIG, while
common/cmd/hoop/main.go duplicates the context commands, aliases, argument checks and help text
already defined by the client. When HOOP_CONFIG is set, wrapper profile commands can read or
change a different file from delegated client commands, and later command or path-rule changes must
be kept in sync across both implementations.

Code

common/cmd/hoop/main.go[R38-39]

+	// The installed release always reads this path. It does not read HOOP_CONFIG.
+	return filepath.Join(home, ".hoop", "config.toml"), nil

Relevance

●●● Strong

Ignoring HOOP_CONFIG causes wrapper and delegated commands to operate on different configuration
files.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The command switch and hard-coded help in common/cmd/hoop/main.go repeat definitions in the
client's context and config commands. The wrapper's defaultConfig hard-codes the default path,
whereas clientconfig.NewPath honors HOOP_CONFIG and the client's load path uses that resolver.

common/cmd/hoop/main.go[33-39] common/clientconfig/clientconfig.go[62-100] client/config/config.go[95-105] common/cmd/hoop/main.go[80-213] client/cmd/config/context.go[13-112]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The wrapper duplicates the client's command definitions and help while ignoring `HOOP_CONFIG`, so wrapper profile commands can operate on a different config file from delegated client commands.

## Fix Focus Areas
- common/cmd/hoop/main.go[33-213]
- common/clientconfig/clientconfig.go[62-83]

## Recommended Fix
Either remove the shim now that the client supports profiles, or derive its help and command behavior from shared definitions and resolve its config path with `clientconfig.NewPath`, including when `HOOP_CONFIG` is empty. Test profile switching and delegation with `HOOP_CONFIG` set.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

dispatch calls recoverBackup on every invocation, while delegate backs up and replaces the
shared config file without coordinating with other wrapper processes. If a second command starts
while a release hoop login is waiting for browser authentication, recovery removes the backup
before the login child saves its flat file; finish then has no backup from which to merge the
credentials, and the other profiles are lost.

Code

common/cmd/hoop/main.go[R42-45]

+func dispatch(args []string, real, configPath string) (int, error) {
+	if err := recoverBackup(configPath); err != nil {
+		return 1, err
+	}

Relevance

●● Moderate

Shared backups create a credible concurrent data-loss race, but fixing it requires broader
process-coordination design.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

delegate writes a backup and a flat config file before running its child, and concurrent processes
use the same backup pathname. A second process can call recoverBackup while the first child is
running; recovery writes the profile document back and removes the backup (lines 382–395). If the
first child subsequently saves, it writes flat TOML over that document. finish detects that the
file differs from what delegate wrote and calls recoverBackup, but the backup is gone, so
recovery returns without restoring the other profiles. No step coordinates these operations across
processes.

common/cmd/hoop/main.go[42-59] common/cmd/hoop/main.go[311-344] common/cmd/hoop/main.go[346-396] client/config/config.go[227-235] common/cmd/hoop/main.go[285-323] common/cmd/hoop/main.go[325-395] common/cmd/hoop/main.go[398-430]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Concurrent wrapper processes share a backup and temporarily replace the same config file. Recovery by one process can remove the backup while another process's child is still running, causing a later credential save to overwrite the profiles with no backup available to merge from.

## Fix Focus Areas
- common/cmd/hoop/main.go[42-59]
- common/cmd/hoop/main.go[285-395]

## Recommended Fix
Hold an exclusive interprocess advisory lock, such as `flock` on `config.toml.lock`, across recovery, backup, child execution, and restoration. Make startup recovery and profile commands wait for the lock or avoid recovery while it is held. Alternatively, use per-process backups that are not recovered while their owner process is alive. Add a test with overlapping delegated commands that both save credentials.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ParseProfileFile splits assignments at the first =, and Marshal inserts spaces around that
split when writing an unknown profile key. If a profile contains the valid TOML assignment `"team=x"
= "one", switching contexts rewrites its key as "team = x"`, changing the setting for any consumer
of that key.

Code

common/clientconfig/context.go[R232-234]

+		for _, extra := range p.Extra {
+			fmt.Fprintf(&buf, "%s = %s\n", extra.Key, extra.Raw)
+		}

Relevance

●●● Strong

Deterministic TOML round-trip bug directly breaks the PR's context-switching feature.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

strings.Cut splits "team=x" = "one" into key "team and raw value x" = "one". The new Extra
path retains those pieces, and Marshal joins them as "team = x" = "one"; UseProfile invokes
that rewrite when selecting a context.

common/clientconfig/context.go[72-77] common/clientconfig/context.go[99-103] common/clientconfig/context.go[232-234] common/clientconfig/context.go[290-303]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A profile switch can change a valid quoted TOML key containing `=` while rewriting unknown fields.
## Fix Focus Areas
- common/clientconfig/context.go[72-77]
- common/clientconfig/context.go[99-103]
- common/clientconfig/context.go[232-234]
- common/clientconfig/context_accounts_test.go[211-250]
## Recommended Fix
Parse the assignment separator outside quoted keys, or retain and emit the original unknown assignment line verbatim. Add a switch test using `"team=x" = "one"` and verify that the key remains unchanged.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ParseProfileFile ignores an unrecognized profile key without retaining its value, and
ProfileFile.Marshal writes only the recognized fields. Switching accounts rewrites the entire
file, so extra keys disappear from inactive profiles as well as the selected one.

Code

common/clientconfig/context.go[R91-93]

+		if err := setProfileField(current, key, raw); err != nil && !errors.Is(err, errUnknownKey) {
+			return ProfileFile{}, fmt.Errorf("line %d: profile %q: %w", lineNo, current.Name, err)
+		}

Relevance

●●● Strong

Rewriting profiles while silently dropping unknown keys causes direct configuration data loss and
violates profile preservation intent.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The parser suppresses errors for unknown profile keys, but Profile has nowhere to store them.
UseProfile then serializes every profile through Marshal, which emits only five credential
fields; the new test explicitly accepts an ignored extra key.

common/clientconfig/context.go[13-22] common/clientconfig/context.go[90-95] common/clientconfig/context.go[203-223] common/clientconfig/context.go[276-289] common/clientconfig/context_accounts_test.go[181-204]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Unknown keys in named profiles are accepted but silently lost when a context command rewrites the configuration file.
## Fix Focus Areas
- common/clientconfig/context.go[91-93]
- common/clientconfig/context.go[203-223]
- common/clientconfig/context.go[276-289]
## Recommended Fix
Preserve unrecognized profile entries in the parsed document and emit them during serialization, including for profiles other than the active one. Test that switching contexts retains an extra key in each profile.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

runtimeBinary falls back to the last usable directory it encounters when the configured active
binary cannot be used. If that binary is missing but older versions remain installed, delegated
commands silently run a version other than the one selected in versions.toml.

Code

common/cmd/hoop/main.go[R496-499]

+		path, ok := usableBinary(candidate, self)
+		if ok {
+			found = path
+		}

Relevance

●●● Strong

Active version is authoritative; scanning can silently select an older release.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The version store identifies the active release as its source of truth, whereas the wrapper ignores
an unusable active selection and returns a different usable binary from its directory scan.

client/upgrade/store.go[20-25] common/cmd/hoop/main.go[479-505]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When the selected release is missing, delegation silently chooses another installed binary.
## Fix Focus Areas
- common/cmd/hoop/main.go[479-505]
- client/upgrade/store.go[20-25]
## Recommended Fix
Treat a configured but unusable active version as an error instead of scanning other version directories; define a separate explicit policy for an absent active selection.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Load now runs the strict ParseProfileFile before falling back to toml.Decode; the custom
parser rejects unknown keys, non-profile tables, multi-line strings, and profile headers with
trailing comments because profileHeader requires ] to end the line. Files previously accepted by
BurntSushi/toml, including one with [profile.work] # production, now cause Load and Save to
fail, affecting hoop login, hoop connect, and other CLI commands.

Code

client/config/config.go[R105-108]

+	profiles, err := clientconfig.ParseProfileFile(data)
+	if err != nil {
+		return nil, fmt.Errorf("failed decoding configuration file=%v, err=%v", filepath, err)
+	}

Relevance

●●● Strong

Strict parsing breaks previously supported TOML files, violating backward compatibility for existing
configurations.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Load returns ParseProfileFile errors rather than falling back to toml.Decode. Within the
parser, setProfileField returns an error for unrecognized keys, profileHeader rejects
non-profile tables, and header lines reach profileHeader unmodified, so a trailing comment fails
its final-] check. Previously, toml.Decode handled these files and tolerated extra keys.

client/config/config.go[101-108] common/clientconfig/context.go[387-445] common/clientconfig/context.go[44-48] common/clientconfig/context.go[425-445]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The strict custom parser gates loading of every config file and rejects files previously accepted by BurntSushi/toml, including files with unknown keys and profile headers followed by inline comments.

## Fix Focus Areas
- client/config/config.go[101-108]
- common/clientconfig/context.go[44-48]
- common/clientconfig/context.go[387-423]
- common/clientconfig/context.go[425-445]

## Recommended Fix
Parse the file with BurntSushi/toml into a struct containing top-level fields and `profile map[string]Profile`, allowing unknown keys to be ignored. If retaining the custom parser, make its result authoritative only when it finds `[profile` headers, otherwise fall back to `toml.Decode`; do not fail on unknown keys, and parse a header’s closing bracket before an optional trailing comment while rejecting non-comment trailing content. Add tests for dotted profile headers with inline comments.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

NewPath calls newHomeDir before checking whether HOOP_CONFIG supplies a complete path. With a
valid override but no usable home directory, loading and profile commands fail before they try the
specified file.

Code

common/clientconfig/clientconfig.go[R91-98]

Relevance

●●● Strong

A complete override path should not depend on resolving or creating the default home directory.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

newHomeDir can return an error while resolving or creating the home directory. NewPath returns
that error before its newly added override branch, and client loading propagates it.

common/clientconfig/clientconfig.go[47-59] common/clientconfig/clientconfig.go[86-101] client/config/config.go[95-105]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A valid HOOP_CONFIG file cannot be used unless default home-directory initialization succeeds first.
## Fix Focus Areas
- common/clientconfig/clientconfig.go[86-101]
- common/clientconfig/clientconfig.go[47-59]
## Recommended Fix
Resolve the client-file override before creating the default home directory; initialize the default directory only when no override is selected.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new common/cmd/hoop executable is not built by the existing development or release targets,
which still compile the client entry point. Consequently, installed hoop invocations never enter
its flatten-and-delegate path, so that compatibility path is unavailable to installed releases.

Code

common/cmd/hoop/main.go[R1-3]

Relevance

●●● Strong

Without build-target integration, the wrapper feature is unavailable in installed releases.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new package declares a separate executable, but both cited build targets still compile client
rather than common/cmd/hoop.

common/cmd/hoop/main.go[1-3] Makefile[78-80] Makefile[375-379]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly added delegation executable is absent from the build and installation paths, so installed clients cannot use it.
## Fix Focus Areas
- common/cmd/hoop/main.go[1-3]
- Makefile[78-80]
- Makefile[375-379]
## Recommended Fix
Either package and install the wrapper as the intended entry point while retaining a separate release binary, or remove the unused compatibility path and rely on the native client commands.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

runtimeBinary searches for a file named hoop in each installed version directory. On Windows,
the version manager installs hoop.exe, so a wrapper installed there reports that no released
binary exists instead of delegating.

Code

common/cmd/hoop/main.go[495]

Relevance

●●● Strong

Using a literal binary name prevents delegation on Windows installations that use the executable
suffix.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The version manager constructs installed binary paths using an OS-specific filename; the wrapper
constructs both candidate paths with the literal name hoop.

client/upgrade/paths.go[22-27] client/upgrade/paths.go[78-84] common/cmd/hoop/main.go[479-500]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The wrapper searches for Unix binary names on Windows, where installed releases have an .exe suffix.
## Fix Focus Areas
- common/cmd/hoop/main.go[479-500]
- client/upgrade/paths.go[22-27]
## Recommended Fix
Share or reproduce the version manager's platform-specific executable naming in both active-version lookup and fallback scanning.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

With HOOP_CONFIG set, NewPath no longer creates the file, and Load now calls os.ReadFile and
returns a hard error when it fails. loadAndValidateConfig treats that as fatal, so
HOOP_CONFIG=./new.toml hoop login exits before it reaches the host prompt or Save. That leaves
the os.IsNotExist fallback added to Save unreachable for login, and the CLI no longer falls back
to localhost mode.

Code

client/config/config.go[R101-104]

Relevance

●●● Strong

Missing override files make login fail before Save, directly breaking the documented HOOP_CONFIG
login flow.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

NewPath returns the override path without creating the file. Load errors when the read fails.
Login only continues on ErrEmpty, so Save, which would create the file, never runs.

common/clientconfig/clientconfig.go[86-100] client/config/config.go[97-104] client/cmd/login.go[81-90] client/config/config.go[224-226]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A missing HOOP_CONFIG file aborts Load, so login can't bootstrap it.

## Fix Focus Areas
- client/config/config.go[101-104]

## Recommended Fix
If `os.ReadFile` fails with `os.ErrNotExist`, treat `data` as empty and keep going: localhost probing, then `return &Config{filepath: filepath}, ErrEmpty`. Login and create can then write the file through `Save`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ParseProfileFile returns an error when current names a profile that isn't in the file, so
readProfilePath fails for use-context, get-contexts, delete-context and Load alike. A user
who hand-edits or removes a section can't switch back with hoop config use-context, and the
fallback message in get-contexts (lines 42-44) never runs.

Code

common/clientconfig/context.go[R88-92]

Relevance

●●● Strong

Invalid current references prevent recovery commands from correcting the selected profile.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The validation at the end of ParseProfileFile returns an error from Active(). Every helper
parses the file first through readProfilePath, so UseProfile never reaches doc.Use(name),
which is the call that would fix current.

common/clientconfig/context.go[88-93] common/clientconfig/context.go[266-280] client/cmd/config/context.go[22-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
An invalid `current` value makes the file unparseable, so it can't be repaired with use-context.

## Fix Focus Areas
- common/clientconfig/context.go[88-93]

## Recommended Fix
Remove the `Active()` check from `ParseProfileFile`. Leave the error to `Active()`/`activeIndex()` callers such as Load and current-context, so `UseProfile`, `ListProfiles` and `DeleteProfile` still work and can reset `current`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

NewPath returns $HOME/.hoop as HoopHomeDir for an override without creating that directory.
When an existing HOOP_CONFIG is used on a machine without .hoop, Kubernetes connect ignores the
failed kubeconfig write and prints a path that does not exist.

Code

common/clientconfig/clientconfig.go[R95-98]

Relevance

●● Moderate

Potentially valid downstream failure, but creating $HOME/.hoop conflicts with the PR’s explicit
override-path behavior.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The override branch constructs and returns the home-directory path without calling newHomeDir.
Both file-loading paths propagate it to Config.HoopHomeDir, while the Kubernetes connection writes
beneath it without creating the parent or checking the write result.

common/clientconfig/clientconfig.go[86-105] common/clientconfig/clientconfig_test.go[56-70] client/config/config.go[112-143] client/cmd/connect.go[424-430]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
With HOOP_CONFIG set, NewPath can return a nonexistent `$HOME/.hoop` directory; Kubernetes connect then prints a kubeconfig path even though writing that file failed.
## Fix Focus Areas
- common/clientconfig/clientconfig.go[95-98]
- client/cmd/connect.go[424-430]
## Recommended Fix
Keep the override from creating its config file, but create the kubeconfig parent directory when needed before writing. Handle write failures instead of printing a path to a file that was not created.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ParseProfileFile applies each occurrence of a credential key or top-level current without
detecting duplicates. A file containing two token, api_url, or current assignments loads with
the last value, so an invalid configuration can silently select different credentials or an account
than its first assignment specifies.

Code

common/clientconfig/context.go[R84-85]

Relevance

●● Moderate

Duplicate credentials are a real validation gap, but strict duplicate-key semantics may be an
intentional parser choice.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The parser repeatedly assigns current and forwards profile keys to direct field assignments
without any seen-key check; client Load now runs this parser on configuration files.

common/clientconfig/context.go[61-85] common/clientconfig/context.go[387-422] client/config/config.go[101-108]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new profile parser silently accepts duplicate keys and uses their last values.
## Fix Focus Areas
- common/clientconfig/context.go[61-85]
- common/clientconfig/context.go[387-422]
## Recommended Fix
Track keys seen in the top-level section and each profile section and return a line-specific error on duplicates, including duplicate current assignments.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools