The core path removes metadata and invisible text carriers
watermark-remover divides its work into distinct layers. Layer A strips invisible Unicode characters, exotic spaces, bidirectional controls, and tag characters through deterministic Python. File cleaners target C2PA, EXIF, XMP, office-document properties, HTML metadata, and container-specific fields. Layer B rewrites text to disturb statistical marks, while optional systems attempt detection or pixel-level image changes. That separation matters because metadata deletion and statistical watermark removal are very different claims.
The format list is broad: common images, SVG, PDF, DOCX, XLSX, PPTX, EPUB, ODT, HTML, Markdown, several video containers, WAV, MP3, and FLAC. Unrecognized formats are left alone, and text commands refuse binary input. The service exposes inspection and cleaning endpoints plus batches capped at 50 files. It binds to 127.0.0.1:8765 by default and can enforce a bearer API key.
Optional tools decide how much a clean operation really does
Core scripts need Python 3.10 or newer, but file depth changes with installed software. The README says PDF cleaning needs qpdf for a real structural strip because ExifTool alone leaves recoverable incremental bytes. Ghostscript is used for metadata inside embedded PDF images. c2patool and ExifTool add other format handling. A report should therefore include detected capabilities, not just a successful HTTP response.
The heavier paths are separate projects or local builds. reverse-SynthID scores images, CtrlRegen attempts pixel-domain removal, MarkLLM checks supported text schemes, and MarkDiffusion provides an image watermark harness. Some work only with the same generation configuration or key. The README calls them detection aids rather than vendor oracles, which is the correct limit. A missing backend fails softly, so automation must read the report rather than equating exit success with full coverage.
What happened when we ran it
Our sandbox installed 55 packages in 28 seconds and used 77 MB on disk. The build succeeded in 7 seconds. The checkout at commit c625344 contained 166 files, about 29,766 source lines, and 3 CI workflow files. Pip-audit found 0 known vulnerabilities in the installed Python dependencies. On size and build time alone, the repository looks easy to inspect.
Tests changed that assessment. The suite ran for 80 seconds and exited 1. The tail lists failures in tests/test_install_skill.py and tests/test_lightweight_skill.py. Several subprocess errors say Python could not open /work/repo/install_skill.py because the file did not exist. Other assertions expected exit code 1 and received 2, which is consistent with the visible command error without proving every failure had the same cause.
The failing names cover personal and linked skill installs, Cowork bundle layout, reproducibility, overwrite refusal, executable scripts, skill listing, unknown-skill handling, and Cursor placement. These are central to the documented agent integration, not an obscure optional model backend. The repository has a tests directory and Compose file, but our scan found no Dockerfile even though the README documents a core image build. Buyers should locate the intended artifact source before trusting either installation route.
The README points to another owner's releases and plugin paths
The reviewed repository is ShadowAqueduct/watermark-remover, yet its badges, release link, Claude Code marketplace commands, and pre-commit example refer to guillaumemeyer/watermarks-remover. GitHub's latest-release endpoint returned Not Found for the reviewed repository. The README nonetheless labels v0.5.0 from the other account as the latest release. That may reflect copied upstream material, but the available evidence does not define the relationship.
This mismatch has practical consequences. A user can clone one owner, install a plugin from another, and pin a pre-commit hook to the second repository without noticing. Our missing install_skill.py failure makes that risk concrete. Confirm which repository is authoritative, compare the exact revision, and inspect marketplace or image publishers before granting a hook permission to examine every file written by an agent.
Automatic clean mode changes files after agent edits
The plugin registers a post-tool hook for write and edit operations. Its default check mode reports marks and leaves files untouched. clean mode strips marks in place after a matching tool call. That can be convenient for a controlled publishing directory, but it is a mutating step attached to broad editor actions. Keep check mode until diff review proves the cleaner preserves the formats and content your team uses.
Text Layer B deserves extra caution. Rewriting may change style and voice, and the project recommends skipping it when quality matters more than watermark hygiene. Use deterministic Layer A and container cleaning first, retain originals, and compare output. No clean result proves that every detector will fail, particularly when the detector uses a secret key, a different model, or a method outside the configured backends.
Authorized privacy work is the defensible use case
The ethics section limits use to content the user owns or is authorized to process. It rejects academic fraud and false claims of human authorship. That boundary should also shape deployment: keep the service local, authenticate it if exposed beyond loopback, log who requested a mutation, and preserve the original where provenance has legal, editorial, or archival value. Removing C2PA may discard useful origin evidence along with unwanted metadata.
GitHub recorded the last push on August 23, 2026, with 6 combined issues and pull requests. The returned open activity consisted of automated dependency upgrades, including large jumps for Transformers and Diffusers. There were no releases under the reviewed owner. The project contains interesting cleaning code, but failed installer tests and unclear repository identity make a read-only inspection trial safer than immediate workflow integration.