fix: suppress gosec G204 warning for trusted local config commands

[euxaristia]

Summary

• Provider command strings are intentionally passed through sh -c / cmd /C to support pipes and env expansions, and originate only from the user's trusted local config
• Gosec flags this as a G204 command-injection risk; removing the shell invocation would be a breaking change, so this adds a documented #nosec G204 annotation instead of degrading functionality

Test plan

• gosec no longer flags internal/config/command.go
• existing provider-command tests still pass

Summary by CodeRabbit

• Chores
  • Added security annotations for provider command execution on supported platforms.
  • No user-visible behavior changes.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: e6773990-2cbe-4606-a96c-6f6e41b77b9f

📥 Commits

Reviewing files that changed from the base of the PR and between 8e26679 and f9d9328.

📒 Files selected for processing (1)

• internal/config/command.go

---

Walkthrough

Changes

Provider command security annotations

Layer / File(s)	Summary
Shell execution annotations internal/config/command.go	Both shell-based provider command execution paths include #nosec G204 annotations. Runtime behavior is unchanged.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested reviewers: anandh8x

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the main change: suppressing the gosec G204 warning for trusted local configuration commands.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Vasanthdev2004]

Approving. I traced the provenance claim rather than taking it at face value, because a #nosec G204 on sh -c is exactly the kind of suppression that ages badly if the input source ever widens.

It holds today. runProviderCommand is reached only from LoadProviderCommand, which has one caller — resolver.go:92, gated on options.ProviderCommand — and that field is populated in exactly one place, paths.go:32, from the ZERO_PROVIDER_COMMAND environment variable. Notably it does not come from ProjectConfigPath, which was my concern: if a project-local config could set it, cloning a hostile repo would be arbitrary code execution, and "the user's trusted local config" would be false. It can't, so the comment is accurate.

Shell evaluation is also the point of the feature here — pipes and env expansion in a provider command only work if a shell sees it — so this isn't a case where the warning could be fixed by dropping to exec.Command with an argv.

One suggestion, non-blocking: it might be worth saying environment variable rather than "local config" in the comment. The load-bearing fact is that the string comes from ZERO_PROVIDER_COMMAND and not from any config file on disk, and naming that makes the suppression self-checking if someone later wires provider commands into the config schema.