How to determine why tsc is compiling a subdirectory

I have a project arranged like so:

project/
  client/
    src/
      client.ts
    tsconfig.client.json
  src/
    index.ts
  tsconfig.json

When I run tsc -b in the project folder, it is attempting to compile the client subdirectory as well. Now I understand that if there is a tsconfig.json in a subfolder, then --build will build that folder, but in this case the subdirectory's tsconfig is renamed.

As a result though, tsc outputs an error:

error TS5083: Cannot read file 'project/client/tsconfig.json'.

How can I go about tracing why tsc is trying to load this folder? client is not listed in the references in the top level tsconfig, and the include and rootDir options are set to only build src.

I've tried doing a --dry build and a --traceResolution but neither provide a helpful answer.

Edit to show my tsconfigs:

project/tsconfig.json

{
  "extends": "../../../tsconfig.base.json",
  "compilerOptions": {
    "outDir": "dist",
    "rootDir": "src",
    "target": "es6",
    "lib": ["es2019","dom"],
    "jsx": "react",
    "noUnusedLocals": false
  },
  "include": ["./src/**/*"],
  "references": [
    { "path": "shared/api" },
    { "path": "../../lib/logger" },
  ]
}

../../../tsconfig.base.json

{
    "compilerOptions": {
      "target": "es2020",
      "module": "commonjs",
      "moduleResolution": "node",
      "rootDir": "packages",
      "baseUrl": "./packages",
      "lib": ["es2019"],
  
      "strict": true,
      "noUnusedLocals": true,
      "noFallthroughCasesInSwitch": true,
      "noImplicitReturns": true,
      "esModuleInterop": true,
      "allowJs": true,
  
      "composite": true,
      "inlineSources": true,
      "sourceMap": true,
      "incremental": true,

      "skipLibCheck": true,
      "emitDeclarationOnly": true,
  
      "allowSyntheticDefaultImports": true,
      "experimentalDecorators": true,
  
      "newLine": "lf",
  
      "noEmitOnError": true,
    },
    "exclude": ["**/jest.config.js", "**/dist", "**/__mocks__/**/*", "**/coverage", "**/gulpfile.js"]
}

client/tsconfig.client.json - if it's relevant, since tsc isn't even using this file

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "strict": true,
    "jsx": "preserve",
    "importHelpers": true,
    "moduleResolution": "node",
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "sourceMap": true,
    "baseUrl": ".",
    "types": [
      "webpack-env",
      "jest"
    ],
    "paths": {
      "@/*": [
        "src/*"
      ]
    },
    "lib": [
      "esnext",
      "dom",
      "dom.iterable",
      "scripthost",
      "webworker"
    ]
  },
  "include": [
    "src/**/*.ts",
    "src/**/*.tsx",
    "src/**/*.vue",
    "tests/**/*.ts",
    "tests/**/*.tsx"
  ],
  "exclude": [
    "node_modules"
  ],
  "references": [
    { "path": "../shared/api" },
    { "path": "../" }
  ]
}

What I discovered is that I was running the tsc command using npx. Since I have workspaces set up in my monorepo, the subfolder had a package.json which npm was picking up and running the tsc command a second time in the subfolder.

Updating my npx command to npx --workspaces=false tsc -b fixes the problem.