A one-use code replaces accounts and SSH setup
Magic Wormhole sends files, directories, or short text between 2 computers. The sender runs wormhole send, reads a short word code, and gives that code to the receiver. The receiver enters it with wormhole receive. The code is used once, so neither person needs an account, a shared cloud folder, an email attachment, or an SSH key exchange. That is the whole appeal.
The connection has more machinery than the conversation does. Both clients contact a mailbox service to find each other and perform a password-authenticated exchange. They then try direct TCP paths using address hints. If those paths fail because both peers sit behind NAT or allow only outbound connections, a transit relay carries the encrypted stream. The relay can observe addresses and traffic timing, but the protocol docs say it cannot read or alter records without detection.
The default code contains 16 bits of entropy. Magic Wormhole's attack notes explain that a network attacker or hostile mailbox server gets one guess and would usually cause a visible failure if it guesses incorrectly. Users who see repeated password errors can request a longer code with --code-length. Anyone who learns the code through the same compromised channel as the file invitation can impersonate a peer, so the code still needs a private route.
What happened when we ran it
Our sandbox installed Magic Wormhole from commit a76c504 in 51 seconds. That pulled 76 Python packages and occupied 106 MB on disk. The build completed in 11 seconds, which puts this closer to an ordinary Python utility than a service stack. No credentials or secrets were present in the unprivileged Debian container.
Pytest finished in 68 seconds with 462 passed, 0 failed, and 10 skipped out of 462. Pip-audit reported 0 known vulnerabilities in the installed dependency set. Those are clean results for the exact commit and environment we ran; they do not measure transfer speed, relay availability, or how the tool behaves with a particular NAT and firewall combination.
The repository held 232 files, roughly 28,240 source lines, and 1.7 MB before installation. Our scan found 3 CI workflow files, no Dockerfile, and no directory literally named tests, even though the invoked pytest suite completed. A container recipe is not necessary for the normal packaged command, but teams embedding the library must own their Python environment and deployment image.
Large directory transfers need a retained source copy
Issue #722 describes a Magic Wormhole 0.24.0 transfer of a 31.53 GB directory containing 10,633 items between macOS and Linux. The progress display reached 100%, then both ends waited without completing. After the receiver was interrupted, the reporter found none of the transferred files. It is a single report, not our lab result, but its failure mode matters because the progress display looked finished before confirmation.
For ordinary handoffs, wait for both clients to report completion and verify the received file before deleting the source. Large directory moves deserve an archive or an independent file list and checksums, particularly when a retry would be expensive. Magic Wormhole is designed as a transfer tool, not a resumable backup system. Its README says files can be arbitrary in size, but that statement does not promise recovery from an interrupted finalization step.
Issue #691 identifies a different boundary: the CLI has no structured output mode. The project's own CLI documentation says commands expect a human and do not try to keep output machine-readable or predictable between releases. Shell automation that scrapes progress or confirmation sentences is therefore brittle by design. Developers should use the Python API, or pick a tool with a documented JSON contract, when another program must make decisions from transfer state.
Tor mode hides address hints only when both sides use it correctly
Normal Transit negotiation shares candidate IP addresses and ports so the peers can attempt a direct connection. The Tor documentation warns that running the command under torsocks or tsocks does not remove those hints. Magic Wormhole's own --tor mode does. It looks for common Tor control or SOCKS endpoints, and --launch-tor can start a temporary daemon if Tor is already installed.
When both clients use Tor, the current implementation does not create onion-service listeners. The docs say file transfers then use the transit relay because neither endpoint advertises a listening address. That protects network location at the cost of a relay dependency and whatever delay Tor adds. The page describes onion-service connections as a future possibility, so buyers should not treat direct Tor transfers as a present feature.
Self-hosting is possible but split across separate repositories. One service provides mailboxes and another runs the transit relay. Both clients must agree on the mailbox, while either side may suggest a relay. Operating those components removes dependence on the public defaults, but it also gives your team availability, abuse control, upgrades, and service discovery to manage. The attack notes explicitly identify the mailbox as a denial-of-service target and single point of failure.
The August 26 push matters more than missing GitHub releases
GitHub recorded a push on August 26, 2026, with open issues and pull requests updated during the same month. The repository had 22,872 stars and 178 open issues and PRs combined when fetched. GitHub's latest-release endpoint returned no release object, so health is better judged from the fresh push and issue work than from that empty release feed.
The core idea has stayed useful because the human workflow is hard to beat: install a command, say a short code, and send the file. Our 462 passing tests support trying it. The caveats are equally concrete. Keep codes private, use the built-in Tor mode when location privacy matters, retain large originals through confirmation, and do not build automation around prose intended for a terminal user.