tongs 1.0.2

Released 2026-09-27. This patch release fixes two security issues in how tongs handles forge credentials, shows where links point in the desktop app, and pins every dependency the release builds install. Everyone should upgrade, and especially anyone who runs the tongs-mcp server. Nothing in your configuration or drafts changes, unless you relied on one of the behaviors described under Security.

Install

pipx install tongs==1.0.2

pip install tongs==1.0.2 and uv tool install tongs==1.0.2 work the same way. To upgrade an existing installation, run pipx upgrade tongs, or uv tool upgrade tongs, or pip install --upgrade tongs. If you use the per-user desktop app, install the matching desktop release after the core:

tongs desktop update

Security

Both issues affect tongs 1.0.0 and 1.0.1 and are fixed in 1.0.2.

• tongs-mcp only talks to configured hosts. (GHSA-4cw3-82cv-q28x, high) The MCP server accepted any hostname that contained github or gitlab, looked up a token for it and sent that token to the host. Because MCP tools are driven by a language model that also reads merge request text, untrusted text could steer a tool call toward such a host. The MCP server now accepts only github.com, gitlab.com and the hosts in your config.toml, exactly like the terminal and desktop apps, and rejects anything else before any credential lookup or request. tongs also no longer guesses the forge type from a hostname anywhere: a self-hosted GitHub or GitLab instance must be listed in config.toml, as the configuration reference already required.
• ~/.netrc is read more strictly. (GHSA-v7v3-jh3w-pj3h, medium) tongs used the default entry of ~/.netrc when no machine line named the forge host, and sent that password as a forge token. Only a machine entry that names the host is used now. A ~/.netrc that cannot be parsed produces an error that names the line, never its contents. Error text returned by the MCP server is redacted, and redaction now also covers ghr_ and glrt- tokens and credentials written into URLs.

If you kept a forge token in the default entry of ~/.netrc, move it to a machine <host> entry. Security and signing describes the full credential lookup.

Reviews

These apply to the terminal app and the desktop app.

• A comment or approval the forge rejects as invalid (GitHub 422, GitLab 400) is reported as a rejected request that you can correct, instead of an unknown outcome that asks you to reconcile the review. Approving your own pull request on GitHub says that GitHub does not allow it. (#315, #333)

The desktop app (beta)

• Links show where they go. Every link in a merge request description or comment names its destination host in its tooltip and to screen readers. When the link text looks like a web address on a different host, such as a link reading github.com/org/repo that points elsewhere, the real host is shown next to it. (#321)
• Desktop plugin assets are checked for symlinks along the whole path from the plugin package, including packages split across several directories, and archive entries with extended tar headers are rejected before they are read. (#329, #334)
• An unexpected failure while submitting a review says so, offers Retry, and no longer suggests refreshing. The desktop service logs the operation and a redacted cause. (#233, #280)

The terminal app

• The inbox has a Forge column that shows GH or GL for each merge request, matching the repository list. (#254, #262)

Release and packaging

• Pinned release builds. The jobs that sign and publish the desktop release, and the job that builds the PyPI packages, install only hash-locked Python packages, including the build backend. The desktop archive builder installs only pinned, hash-checked RPMs with every package repository disabled. Every CI workflow keeps its checkout credentials out of the working tree and has a timeout, and a test checks all of this for every workflow. (#303)
• The companion Python RPM changelogs name the project’s packaging address. (#327, #335)
• The pull request template reminds contributors to update the known issues page when a fix lands. (#332)

Release assets

The GitHub Release carries the same set of assets as 1.0.1, for version 1.0.2: the per-user archive with its release manifest and Sigstore attestation, the unsigned Fedora 44 RPMs with their source-built companion packages, the archive SBOM with its attestation, and SHA256SUMS. Install the RPMs together with dnf install ./*.rpm.

Known issues

Known issues lists the defects known in 1.0.2, with the issue and milestone for each fix. The next patch releases, 1.0.3 through 1.0.9, each fix one group of them.

Several fixes in this release were planned for later patch releases and arrived early as community contributions. Thanks to @GhostCoder6969, @tayfuryldz and @Tiyatrotist for their work.