Where this is going.

Now

• 1.0.0 is out. Verified on macOS 26.5.2 arm64 and on Linux aarch64 and x86-64, with gcc 11–13 and clang 18. 741 checks, 8/8 suites, zero warnings. The tool does what this site says it does.
• Field reports. The most useful thing right now is JPEGs from cameras and phones the fixture corpus does not cover. A file this misreads is worth more than a description of how it misreads it.

Next

• A Homebrew tap. Single biggest usability win left. git clone && make is a small ask for developers and a large one for everybody else. Nothing is published yet, and the install page will not print a brew install line before there is one to run.
• A manual page. --help covers the flags, but man scrubpony is where people look, and it belongs in make install.
• Wider platform reports. The BSDs should work untouched — same POSIX surface — but they are untested rather than supported, and that wording only changes when somebody has actually run the suite there.

Exploring

These are under consideration, not commitments. They ship when they can be done right, or not at all:

• PNG. The obvious next container: tEXt, iTXt, zTXt and eXIf chunks are a smaller problem than JPEG's segments. The question is whether it can be done without the codebase growing the sort of abstraction that makes the pixel claim harder to check.
• Prebuilt binaries. Attractive, and a real supply-chain question: a downloaded binary is a thing you have to trust, where source you compiled yourself is not. If it happens it happens with reproducible builds and signatures, or it does not happen.
• A policy file. Letting the keep/drop table be overridden per-run. Tempting, and also the fastest route to somebody configuring themselves back into leaking GPS. Probably no.
• Parallel walking. 1,200 files in 3.2 seconds is already fast enough that this is a solution looking for a problem. It would be revisited if somebody turns up with a library where it is not.

Not planned

• Windows. Out of scope by design. O_NOFOLLOW, POSIX permission bits and rename-over-an-existing-file all behave differently there, and those are exactly the things the safety guarantees rest on.
• Editing metadata. Removing is a much smaller problem than writing, and keeping the scope there is what makes "provably did not touch the pixels" a claim worth making. exiftool already does the writing job well.
• A GUI. It reads directories. That is the interface.
• Re-encoding, resizing, or watermark removal. All three would mean touching pixels, which is the one thing this tool exists not to do.

Have an opinion on priorities? Tell the developer directly — the roadmap genuinely bends to real feedback.