Works perfectly for me. I'll leave the pull request open for the time being, then. Have a good one!

Other tooling that are non-Python project have support for them:

From a quick look most of these have some kind of Python connection even if they aren't written in Python themselves (for example Ruff lints Python, even though it happens to be written in Rust).

For zizmor the connection is much more tenuous: it's distributed through PyPI for convenience (and because a lot of Python developers use it), but it has no actual connection to Python packaging or Python project metadata.

Given that I'm pretty hesitant to support pyproject.toml as a configuration source.

(There's also the separate precedence/order issue noted above.)

Just to keep track of the support landscape, lychee just added support for [tool.*] in pyproject.toml, as well as Cargo.toml and package.json in the upcoming v0.24 release. See: lycheeverse/lychee#1930 (comment) and lycheeverse/lychee#2104

As for the "precedence/order issue", here is my benchmarking of existing tools:

Looking at other projects, a dedicated configuration file wins over pyproject.toml. In which case it is completely ignored and not merged at all.

Examples of strict precedence:

• Ruff: .ruff.toml > ruff.toml > pyproject.toml (source)
• Uv: uv.toml > pyproject.toml (source)
• Typos: either typos.toml / _typos.toml / .typos.toml, then > Cargo.toml > pyproject.toml (source)

I guess the reason for the strict no-merge policy is to avoid confusion and surprises: only one source of configuration.

As for the dedicated file precedence, it feels like a file at the root of a repository, named after your tool, is way more visible and explicit than a section in pyproject.toml.

As for my personal preference, I like tool-dedicated sections in pyproject.toml to keep the root of my repository clean. And review my tools configurations altogether in a centralized place. Because more often that not, I need to tweak the configuration of tools and coordinate them so they can play nice with each others.

In the end I implemented a "tool runner" in repomatic that translates [tool.zizmor] sections from pyproject.toml into zizmor's native YAML config, caches the result, and passes it via --config. No changes needed in zizmor itself.

So now you can have a pyproject.toml that looks like:

[tool.zizmor]

[tool.zizmor.rules.artipacked]
disable = true

[tool.zizmor.rules.unpinned-uses]
config.policies."*" = "ref-pin"

With a workflow in .github/workflows/ci.yaml:

name: CI

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Hello"

Then run zizmor via repomatic:

$ uvx repomatic run zizmor -- .
🌈 zizmor v1.23.0
 INFO audit: zizmor: 🌈 completed ./.github/workflows/ci.yaml
warning[excessive-permissions]: overly broad permissions
  --> ./.github/workflows/ci.yaml:8:3
   |
 8 | /   build:
 9 | |     runs-on: ubuntu-latest
10 | |     steps:
11 | |       - uses: actions/checkout@v4
12 | |       - run: echo "Hello"
   | |                          ^
   | |                          |
   | |__________________________this job
   |                            default permissions used due to no permissions: block
   |
   = note: audit confidence → Medium

4 findings (3 suppressed): 0 informational, 0 low, 1 medium, 0 high

As you can see the [tool.zizmor] config is applied, as the artipacked rule is suppressed, unpinned-uses accepts tag-pinned refs like @v4, and only the excessive-permissions finding is reported.

This bridges the gap for Python projects that want to centralize all tool configuration in pyproject.toml without requiring native support from each tool.