Codecov Fork PR Comment Permission Setting Interaction

Direct answer

Most likely, no: the repository-level Allow fork pull requests to post comments setting is the primary gate, and a maintainer's approval of a fork PR does not override it. When the setting is disabled, Codecov suppresses comments on fork PRs regardless of approval. When it is enabled, maintainer approval is the main gate — but not the only one.

Important caveat: the precise interaction between these two layers is not fully pinned down in public documentation and may vary between Codecov cloud and self-hosted deployments. Treat the override semantics as unconfirmed until you run the empirical test described below.

Two independent layers that are easy to conflate

The confusion usually comes from mixing up two separate mechanisms:

• GitHub's fork workflow approval (the "approve and run" button for workflows from forks) controls whether CI executes at all. It says nothing about what Codecov does with the results.
• Codecov's fork comment setting controls whether Codecov will post a coverage comment on a PR originating from a fork. This is a Codecov-side policy, applied after upload.

Approving the workflow run satisfies the first layer only. If Codecov's setting is disabled, the second layer still blocks the comment even after a successful upload.

When the setting is enabled: approval is necessary but not sufficient

Even with the fork setting on and the workflow approved, a comment can still be silently absent. Additional conditions include:

1. Successful upload. Fork PRs from public repos typically use tokenless uploads. If the upload fails, is flagged, or never reaches Codecov, there is nothing to comment on.
2. App permissions. The Codecov GitHub app must retain permission to comment on the repository.
3. codecov.yml comment rules. Settings such as comment: false, require_changes, or require_base/require_head can independently suppress comments. This is a common hidden cause.

How to verify in your repository

Because the exact semantics are version- and plan-sensitive, the reliable answer is a controlled test:

1. Disable the fork comment setting. Open a test fork PR, have a maintainer approve the workflow run, confirm the upload succeeds in the CI log, and check whether a comment appears.
2. Enable the setting, open another fork PR without approval, and confirm no comment is posted — this validates that approval is the operative gate.
3. Inspect the uploader output in CI for fork- or comment-related messages, and review codecov.yml for any comment: rules.

# codecov.yml — rules that can suppress comments independently
comment: false          # disables comments entirely
# or:
comment:
  require_changes: true # only comment when coverage changes

If your test shows a comment appearing with the setting disabled, that would contradict the expected behavior and is worth reporting to Codecov support with the upload logs.

Why the setting exists

Fork PRs can modify CI configuration, so allowing comments by default creates an avenue for leaking coverage data or abusing the integration via malicious pull requests. Codecov therefore defaults to a conservative posture for forks, which is consistent with the setting acting as a hard gate rather than a soft preference that approval can bypass.