Feature request: fall back to base-branch `.coderabbit.yaml` when feature-branch lacks one (fork PRs)

[flitzrrr]

Summary

CodeRabbit currently reads .coderabbit.yaml only from the PR's source/feature
branch. When the source branch does not contain the file, CodeRabbit silently
falls back to defaults instead of inheriting from the base branch.

This breaks the developer experience for two common cases:

1. Fork PRs from contributors whose fork was created BEFORE the maintainer added
   .coderabbit.yaml to the upstream default branch. The contributor's branch
   does not have the file; CodeRabbit ignores the upstream config entirely.
2. Internal feature branches created BEFORE the config landed on main and not
   rebased. Same symptom.

In both cases the maintainer's intent (via .coderabbit.yaml on main) is silently
ignored, with no warning surfaced in the PR.

Reproduction (real-world)

• Repo: https://github.com/klein-business/legal-text-mcp-de
• PR: docs(examples): add Docker Compose HTTP deployment example klein-business/legal-text-mcp-de#107
• Source: fork RounakSharma2005/legal-text-mcp-de, branch
  add-docker-compose-example (created 2026-05-18 12:55 UTC)
• .coderabbit.yaml on klein-business/legal-text-mcp-de main: merged at
  2026-05-18 22:03 UTC (PR #108)
• Asked @coderabbitai configuration on PR #107 → response:
  Configuration used: defaults with poem: true, path_filters: [],
  path_instructions: [] — i.e., none of the upstream config was applied.
  (comment link)

Expected behaviour

When the source branch has no .coderabbit.yaml, CodeRabbit should:

1. Look up the file from the base branch
2. Apply it
3. Surface a single-line note in the bot's first comment:
   Configuration source: base branch (main)

Current workarounds (none are good)

• Maintainer pushes .coderabbit.yaml to the contributor's fork branch —
  works because "Allow edits by maintainers" is default-on, but it's a
  maintainer anti-pattern (silently injecting config into someone else's PR
  for a setting that is the maintainer's concern, not the contributor's).
• Ask the contributor to sync their fork — fine in theory, terrible UX
  for a first-time contributor whose only deliverable is the change in their
  PR.
• Accept default-config reviews on fork PRs from older forks — silently
  breaks settings like poem: false, path_filters, path_instructions,
  and tone_instructions. Maintainers don't know their config was ignored
  unless they explicitly ask @coderabbitai configuration.

Suggested behaviour

Three-tier lookup, in priority order:

1. Source/feature branch .coderabbit.yaml (current behaviour, preserved)
2. Base branch .coderabbit.yaml (new fallback)
3. Defaults

With a single-line note in the bot's first comment indicating which tier was
used, so maintainers can spot config-not-loaded situations at a glance.

Optional refinement: a per-repo setting inherit_base_config: true so
maintainers can opt out for hyper-strict setups.

Why this matters

For OSS maintainers running a contributor funnel (CodeRabbit Pro for OSS is
$0 — brilliant), the bot is the consistency layer — every external PR
should get the same review experience as internal PRs. The current behaviour
creates a two-tier experience: internal PRs get the maintainer's intent;
fork PRs get defaults. That defeats most of the point of maintaining a
.coderabbit.yaml in the first place.

Happy to test a beta on klein-business/legal-text-mcp-de if you'd like a
guinea-pig repo.

---

(Filing here because coderabbitai/awesome-coderabbit is the closest public
issue tracker; happy to move if there's a better venue.)