config clear --all removes the legacy Drive cache but not the legacy config dir

[rianjs]

Symptom

After the platform-config-dir migration (#134), a user with a pre-MON-5371 install on macOS or Windows has files in both the legacy ~/.config/google-readonly/ directory and the new os.UserConfigDir/google-readonly/ directory.

Running gro config clear --all followed by gro init does not get them to a clean state:

1. clear --all removes the keychain token, the new-location config.yml, the new-location Drive cache, and the legacy Drive cache.

2. It does not remove the legacy config file (~/.config/google-readonly/config.json or config.yml).

3. On the next gro init, DetectConfigRelocation sees the legacy file is still present, the new dir is missing (we just removed it), so it returns relocOldOnly with CopyNeeded=true, then ApplyConfigRelocation copies the legacy file forward.

4. If the user has independently re-created the new-location file (via, say, an installer that drives gro init in a loop or a partial intermediate run), step 3 instead returns relocBothDivergent and gro init refuses to proceed:

   warning: config: shared old/new config diverge: old /Users/x/.config/google-readonly/config.json and new /Users/x/Library/Application Support/google-readonly/config.yml have different settings; reconcile (or delete one) before running gro init

Why this looks like an oversight

runClear --all in internal/cmd/config/config.go explicitly handles both the new and legacy cache dirs:

if cacheDir, cerr := config.CacheDirPath(); cerr == nil {
    if rmErr := os.RemoveAll(cacheDir); rmErr != nil {
        return fmt.Errorf("removing Drive metadata cache %s: %w", config.ShortenPath(cacheDir), rmErr)
    }
    fmt.Printf("Removed Drive metadata cache at %s.\n", config.ShortenPath(cacheDir))
}
if legacy, lerr := config.LegacyCacheDir(); lerr == nil {
    if rmErr := os.RemoveAll(legacy); rmErr != nil {
        return fmt.Errorf("removing legacy Drive cache %s: %w", config.ShortenPath(legacy), rmErr)
    }
}

The comment above this block makes the intent clear:

Drive metadata cache: an explicit full reset removes BOTH the current cache dir and the legacy (pre-B2b) one directly — no cache.New(), so no migrate-then-delete dance and no MkdirAll side-effect.

But the equivalent block for the config file removes only the new-location cfgPath. The legacy config dir's config.{json,yml} is never touched. The asymmetry between cache (both removed) and config (only new removed) reads as the config-side cleanup not being updated when MON-5371 introduced platform-specific config dirs (the cache-side cleanup landed in B2b / #130; MON-5371 landed in #134 but didn't extend clear --all).

I think the ApplyConfigRelocation copy-leave-old policy is the right default for init — the legacy file is a recovery point for the user. But for an explicit clear --all ("Also remove config.yml and the Drive metadata cache"), the user is asking for a full reset; leaving the legacy file behind defeats the operation and silently re-creates the divergence trap on the next init.

Proposed fix

In runClear, after os.Remove(cfgPath), also remove the legacy config file. Something like:

if legacyDir, lerr := config.LegacyConfigDir(); lerr == nil {
    for _, name := range []string{config.ConfigFileYAML, config.ConfigFile} {
        legacyPath := filepath.Join(legacyDir, name)
        switch err := os.Remove(legacyPath); {
        case err == nil:
            fmt.Printf("Removed legacy %s.\n", config.ShortenPath(legacyPath))
        case os.IsNotExist(err):
            // fine
        default:
            return fmt.Errorf("removing legacy %s: %w", config.ShortenPath(legacyPath), err)
        }
    }
}

Notes:

• The OAuth client JSON in the legacy dir is still preserved (consistent with the existing "never removed" guarantee for deployment material).
• A LegacyConfigDir() helper would need to exist or be added; the package already has LegacyCacheDir() as precedent.
• --dry-run would need parallel updates so users see what --all will actually remove before running it.

Impact today

Downstream installers (claude-desktop-mcp PRs #31 Windows + #32 macOS) currently work around this by running gro config clear --all and then os.unlink-ing the legacy config.json themselves before invoking gro init. Moving the cleanup into gro itself would let downstream installers drop that workaround.

Repro

On a fresh macOS box:

1. Seed ~/.config/google-readonly/config.json with {} and ~/Library/Application Support/google-readonly/config.yml with credential_ref: foo/bar.
2. gro config clear --all — succeeds.
3. ls ~/.config/google-readonly/ — config.json is still there.
4. Touch ~/Library/Application Support/google-readonly/config.yml with anything → gro init → divergence warning.

Happy to PR if useful.

[rianjs]

MON-5433 — gro: config clear --all should remove the legacy config file, not just the legacy cache

GH issue: #137
Jira: MON-5433 (Bug, 2 pts, parent INT-310)

Problem

After MON-5371 (#134) moved gro's config dir from ~/.config/google-readonly/ to the OS-native os.UserConfigDir/google-readonly/ on macOS/Windows, gro config clear --all:

• removes the keychain token ✅
• removes the new-location config.yml ✅
• removes the new-location Drive cache ✅
• removes the legacy Drive cache (LegacyCacheDir) ✅
• does NOT remove the legacy config file (<old-hand-rolled-dir>/config.{yml,json}) ❌

The legacy config file then re-arms the divergence trap on the next gro init: DetectConfigRelocation sees old-only-present → relocOldOnly → ApplyConfigRelocation copies the legacy file forward. If the user has independently re-created the new-location file, the next init returns relocBothDivergent and refuses to proceed.

The asymmetry is exactly: the cache side got both-dir cleanup (B2b / #130); the config side did not get the analogous treatment when MON-5371 introduced the dir relocation (#134).

Why MON-5371 missed it

§6.6 pattern 5 (cli-common docs) covered the companion-secret-file cleanup symmetry (migrator + cleanup share a candidate-enumeration helper for token.json/credentials). It did not explicitly cover the underlying config file itself when the config dir relocates — that one slipped past pattern 5's lens because gro's --all scope is documented as "config + cache only", which read as "yes, the config is covered" without anyone checking the legacy-side symmetry that the cache half already had.

Scope

gro only. Other CLIs are unaffected:

• atlassian-cli was a fresh monorepo — no pre-MON-5370 legacy config dir on macOS/Windows.
• nrq, slck — credentials/companion files relocate via §1.8 keychain migrator, not via a wholesale config-dir relocation that strands an old config.{yml,json}.
• gro is the only family member where the config-dir was hand-rolled then relocated AND has a legacy config.json form.

No cli-common docs update — see [[cli-filesystem-standard]]; the workstream is closed.

Fix (surgical)

1. Add LegacyConfigDir() to internal/config/config.go

Mirror the existing LegacyCacheDir() shape — public, non-creating, delegates to oldHandRolledConfigDir (which already exists, unexported, in relocate.go).

// LegacyConfigDir resolves the pre-MON-5371 hand-rolled config directory
// (~/.config/google-readonly on macOS/Windows; identical to the canonical
// dir on Linux) WITHOUT creating anything. Symmetric with LegacyCacheDir
// — exposed so config clear --all can scrub the legacy config.{yml,json}
// the same way it scrubs the legacy cache.
func LegacyConfigDir() (string, error) {
    return oldHandRolledConfigDir()
}

2. Extend runClear in internal/cmd/config/config.go

After the existing os.Remove(cfgPath) block under if all, add the legacy-config scrub. Iterate both filenames (covers config.yml and the pre-migration config.json). Linux short-circuit handled by path identity: when LegacyConfigDir == newDir, the YAML attempt is a no-op (already removed by the new-dir scrub), the JSON attempt may still catch a legacy artifact on Linux.

if legacyDir, lerr := config.LegacyConfigDir(); lerr == nil {
    for _, name := range []string{config.ConfigFileYAML, config.ConfigFile} {
        legacyPath := filepath.Join(legacyDir, name)
        if legacyPath == cfgPath {
            continue // Linux path-identity: already handled above
        }
        switch err := os.Remove(legacyPath); {
        case err == nil:
            fmt.Printf("Removed legacy %s.\n", config.ShortenPath(legacyPath))
        case os.IsNotExist(err):
            // not present — fine
        default:
            return fmt.Errorf("removing legacy %s: %w", config.ShortenPath(legacyPath), err)
        }
    }
}

OAuth client JSON in legacy dir is intentionally NOT removed (consistent with the existing "OAuth client JSON is deployment material, never auto-removed" guarantee — see runClear's trailing note).

3. --dry-run parity

Mirror the legacy-config probe in the if dryRun block — non-creating, just os.Stat to decide whether to print "Would remove" for each legacy file. Same Linux path-identity dedup.

4. Tests

Add to internal/cmd/config/config_test.go (or wherever runClear is tested):

• TestConfigClearAll_RemovesLegacyConfig: seed both <legacy>/config.json and <new>/config.yml (use the same synthetic-distinct-dir technique as relocate_test.go's setupRelocPair); run runClear(all=true, dryRun=false); assert both legacy and new are gone.
• TestConfigClearAll_DryRunReportsLegacyConfig: same seed; run with dryRun=true; assert stdout contains "Would remove" lines for both; assert legacy file still present on disk.
• TestConfigClearAll_DivergenceTrapDoesNotRearmAfterClear: full repro of the issue's "Repro" section — seed legacy config.json + new config.yml, run clear --all, then call DetectConfigRelocation(), assert Kind == relocNone (no relocOldOnly, no divergence-trap re-arm).
• TestConfigClearAll_LegacyAbsent_NoError: only the new-location file exists; clear --all succeeds, no spurious "Removed legacy" line.
• Linux path-identity dedup: on Linux (old==new), assert the dedup continue fires (we don't double-print "Removed legacy …" for the YAML).

Reuse statedirtest.Hermetic(t) for env isolation, matching the MON-5371/5373 family.

Out of scope

• OAuth client JSON cleanup in legacy dir (preserved per deployment-material policy).
• LegacyTokenDir-style helper (token cleanup already routes through keychain migrator, not file scrub — §6.6 pattern 5 caveat).
• Any change to ApplyConfigRelocation (the migrator's "copy-leave-old" policy is intentional; the bug is in --all, not in init).
• cli-common docs update (workstream is closed; other CLIs not affected).

Verification

• make check passes (tidy, lint, test, build).
• New tests pass; existing 450-test suite stays green.
• Manual repro from the issue's "Repro" section no longer reproduces — after gro config clear --all, ls ~/.config/google-readonly/ (on a macOS dev box) shows the config files removed.

Risk

• Path-identity-dedup on Linux is the only subtle bit; the continue test pins it.
• File-removal is idempotent (os.IsNotExist tolerated) — no failure mode where partial scrub leaves the user worse off than today.
• No changes to keychain, init, relocation migrator, or any other family-shared contract.