gowitness 3.2.0 - Chrome Profile Reuse and Screenshot Names

gowitness 3.2.0 from sensepost shipped on 14 September 2026. The change that matters most for capture pipelines is --chrome-user-data-dir, which starts Chrome from an existing user data directory so an authenticated session can survive across runs. The same tag also stops cutting screenshot filenames short, improves cookie isolation, and switches the container base to a maintained headless Chrome image.

The full release notes and downloads are on the GitHub release page. The range from 3.1.1 to this tag is the full changelog. The maintainers call 3.2.0 a minor release.

gowitness launches Chrome, loads a URL, and writes a screenshot. --chrome-user-data-dir tells that launch to use an existing Chrome user data directory. The notes name two uses: an existing authenticated context, and session reuse across gowitness runs.

A pipeline that screenshots a page behind a login can prepare the profile once, keep the directory on disk, and pass the same path on later runs. Site data already in that profile stays available after the process exits.

The flag landed in commit a11f5a4 from @ChrisJr404, merged as pull request 316. Only --no-log-color is described as a global flag. Confirm the path is accepted before you wire --chrome-user-data-dir into a scheduler.

The cost is shared state. Every run that points at that path sees the same profile. Leave the flag unset when each URL must start clean. Set it when the job needs a logged in session that outlives the process. Treat the directory as a credential store, and do not hand the same path to untrusted jobs.

The fixed list has a single entry. Screenshot filenames were still being truncated, and commit 8cce510 is the patch meant to stop that. @sw-mwieland wrote it, merged as pull request 319. The release text frames the bug as one that had survived earlier attempts.

The notes do not record the old length limit or the new filename pattern. A truncated name drops the tail of a long URL, so a job that rebuilds the address from the file name loses that tail. Names that 3.1.1 truncated can differ once 3.2.0 writes them. Check joins that key on the file name before you replace the binary on a batch path.

Three commits sit under the other heading. None of them adds a command.

Commit 63d6b3e pairs a small performance improvement with better cookie isolation. There is no benchmark, so the speed claim stays at small. A crawl that renders many URLs in one process is where isolation matters: a cookie set for one target should stay off the next target. --chrome-user-data-dir is the separate control, and it keeps one profile together across runs.

Commit 55c855c improves go-rod Chrome discovery. go-rod is how gowitness launches and drives Chrome, and discovery is how that library finds the browser binary. Retest workers that already failed to find Chrome. If discovery still fails, this tag does not document another switch.

Commit 4f56290 switches the container build to a maintained chrome-headless image as its base. A base image change can move the browser and the OS packages under the binary even when the application tag only steps from 3.1.1 to 3.2.0. If you build an image from this repository, read the Dockerfile at tag 3.2.0 for the registry and the pin, then pin a digest. Published binaries never hit this base.

The GitHub release page publishes checksums for darwin amd64 and arm64, linux amd64, arm, and arm64, and windows amd64 and arm64. Asset names follow gowitness-3.2.0-linux-amd64. The windows files end in .exe.

Commit 37426fb adds --no-log-color as a global flag. Color here is ANSI control codes mixed into the text. Line collectors and grep both trip on those codes. The flag turns color off for the process. Set it in CI and in batch runners.

The rest of the tag is dependency bumps across Go, TypeScript, and CI, with no module list and no version list in the release text. Building from tag 3.2.0 changes the toolchain even though the bumps add no capture feature. Run a known URL list and compare screenshot names before you put the new binary on a schedule.