What version of Oxlint are you using?

1.58.0

What command did you run?

No response

What does your .oxlintrc.json (or oxlint.config.ts) config file look like?

What happened?

When a child directory has its own oxlint.config.ts that overrides a rule from a parent config (e.g., sets eslint/no-console to "off"), the override is not applied during linting — the parent's "error" setting still takes effect. However, --print-config correctly shows the merged result as "allow".

This indicates a discrepancy between config resolution in --print-config and the actual lint execution path.

Reproduction

Repo: https://github.com/YKDZ/oxlint-nested-config-repro

oxlint.config.ts          # "eslint/no-console": "error"
child/
  oxlint.config.ts        # "eslint/no-console": "off"
  test.ts                 # console.log("hello");

git clone https://github.com/YKDZ/oxlint-nested-config-repro.git
cd oxlint-nested-config-repro
npm install

# ❌ BUG: reports 1 error (no-console), child override not applied
npm run test:bug

# ✅ Workaround: 0 errors — disabling nested discovery + using extends works
npm run test:workaround

# Shows no-console: "allow" — config merging is correct here
npm run test:print-config

Variant: with explicit extends

The same bug occurs when the child config uses extends: [rootConfig]:

// child/oxlint.config.ts
import { defineConfig } from "oxlint";
import rootConfig from "../oxlint.config.ts";
export default defineConfig({
  extends: [rootConfig],
  rules: {
    "eslint/no-console": "off",
  },
});

In both cases (with or without extends), the child's "off" is ignored at runtime.

Expected Behavior

Running oxlint from child/ should apply the child config's "eslint/no-console": "off", resulting in 0 errors. This matches what --print-config reports.

Actual Behavior

Running oxlint from child/ reports a no-console error, as if the parent config's "error" takes final precedence. --print-config shows "allow" (correct merged value) but the linter does not honor it.

Workaround

Using --disable-nested-config and relying on explicit extends: [rootConfig] in the child config produces the correct behavior (0 errors).

Environment

• oxlint: 1.58.0
• Node.js: v24.x
• OS: Debian 12 (bookworm) / Linux