[Bug]: Secret decryption fails with correct passphrase #40

[pandey03muskan]

Type of Change

• Bug fix

Description

forge secret set/get/list/delete commands were failing with decryption failed (wrong passphrase?) when run from inside a project directory, even with the correct passphrase.

Root cause: parseSecretsPath() in forge-cli/cmd/secret.go scanned forge.yaml line-by-line for any path: key. Every standard forge.yaml has skills: path: SKILL.md — after strings.TrimSpace, that line matched first, so the CLI was trying to AES-256-GCM decrypt SKILL.md as if it were an encrypted secrets file.

forge run was unaffected because Runner.buildSecretProvider() hardcodes the secrets file paths and never calls parseSecretsPath.

Fix:

parseSecretsPath now tracks the secrets: top-level YAML block and only matches path: keys within that block
Extracted resolveSecretsPath() as a single shared function so the displayed path and the actual provider path are always consistent

General Checklist

• Tests pass for affected modules (go test ./...)
• Code is formatted (gofmt -w)
• Linter passes (golangci-lint run)
• go vet reports no issues

[initializ-mk]

Bug confirmed — parseSecretsPath() matches the first path: line in forge.yaml regardless of YAML nesting. In a standard config, skills.path: SKILL.md appears before secrets.path, so the CLI tries to decrypt SKILL.md as an encrypted secrets file.

Fix is correct — tracking the secrets: top-level block via indentation before matching path: resolves the ambiguity. The resolveSecretsPath() extraction also fixes the display/actual path inconsistency.

Minor suggestions:

• The blank-line removals in encrypted_file_provider.go (Delete and ensureLoaded) are unrelated cosmetic changes — consider dropping them to keep the diff focused.

No new bugs introduced. LGTM.