Understand what changed: project identity, UI branding, and filenames may differ
If a search for Mihomo Party now leads to Clash Party, do not decide that one is an unrelated client from its icon or filename. The current first-party entry is the mihomo-party-org/clash-party repository, whose repository name and project description use Clash Party. Following the organization and repository gives you a verifiable project identity that a third-party download page cannot establish merely by changing a heading.
A rename rarely reaches every surface at the same moment. The repository, application title, package filename, installed-app label, data directory, updater metadata, and older documentation may retain different names across versions. A mihomo-party prefix is therefore not automatically counterfeit, while a clash-party prefix is not automatically authentic. The decisive questions are whether the asset is listed by the same official Release, whether platform and architecture match, and whether its checksum can be paired with that asset.
The application and core are different layers: Clash Party is the desktop client project name, while Mihomo remains the name of the core it uses. A UI rename is not an instruction to replace every occurrence of Mihomo inside a configuration.
Do not infer a license change, a data-directory move, or guaranteed compatibility solely from the rename. Those claims require release notes or code evidence. A stable existing installation does not need an urgent upgrade merely to display the newer name. When an update is otherwise appropriate, treat the transition as a normal software migration with a source chain and rollback.
Enter Releases from the official repository instead of a filename search
Start with the repository organization and then open Releases from inside it. Confirm that the URL belongs to mihomo-party-org and the repository is clash-party. On the intended version, record the tag, publication context, exact asset name, size, and any SHA-256 sidecar. A tutorial can explain menus, but it should not become the sole source for an executable.
- Open the official repository and verify the organization, repository name, and description.
- Use its Releases link and choose an explicit version rather than a generic latest button elsewhere.
- Filter assets by operating system, CPU architecture, and installation format.
- Download the SHA-256 file paired with the chosen asset and verify it locally.
- Keep the Release URL and original filename as part of the installation record.
An extension identifies packaging more reliably than architecture. Windows may offer an installer and archive; macOS packages may distinguish Intel and Apple chips; Linux releases can cover several package formats and CPU families. Determine the machine architecture and acceptable format first. A smaller mirror file, a simpler name, or a faster third-party server is not evidence that it is the right build.
A repost is not automatically an official mirror: only a distribution location explicitly linked by the project carries the first-party source chain. Even an unchanged-looking filename on a file host requires independent verification.
When one Release has two prefixes, pair platform, asset, and checksum
The official v2.0.2 Release provides a concrete transition example. Its Assets list includes filenames beginning with both clash-party- and mihomo-party- for Windows, macOS, and Linux, along with related .sha256 files. Because both families are listed under the same official tag, the prefixes alone do not support a claim that they are two unrelated products.
| Observed clue | Supported interpretation | Unsupported leap |
|---|---|---|
| clash-party prefix | asset using the current project name | it must use a completely new data path |
| mihomo-party prefix | transition or compatibility naming | it must be obsolete or malicious |
| same v2.0.2 tag | assets listed by one Release | any external file with that name is trusted |
| .sha256 sidecar | local content can be checked | source provenance no longer matters |
Match the operating system and architecture before interpreting the prefix, then read the notes for that exact tag. If two families remain for the same platform, do not install both as an experiment or overlay one with the other. Select one asset that can be fully tied to the Release and its checksum after making a backup. If the notes do not explain a distinction, pause and consult first-party discussions instead of inventing a feature difference.
SHA-256 detects a truncated or changed local download, but only when the expected digest comes from the trusted Release. Preserve original filenames, calculate the complete local digest, and compare the whole string. File size and a few matching characters are useful screening clues, not a complete verification.
Back up user data and separate a successful launch from a successful migration
A renamed build may read the existing data directly, or packaging identifiers and version gaps may lead it elsewhere. Do not assume a seamless migration and do not preemptively rename a data directory. In the working client, record the full version, profile names, selected mode, important overrides, and core status. Use the client’s export or backup function where available. If copying its data directory, exit the application fully and treat subscription tokens inside the copy as secrets.
Preserve program recovery and user-data recovery separately. An old installer or untouched portable folder can restore the application; an export and a complete data snapshot can restore working state. Neither substitutes for the other. When space permits, test the new package in a reversible environment. Do not uninstall the old version with a remove-user-data option before confirming where and how the new build reads configuration.
- Record the old display name, exact version, and original download source.
- Export configuration and copy the actual data directory while the app is stopped.
- Capture sanitized profile names, selected groups, and important overrides.
- Open the backup location and confirm that files exist, are non-empty, and sit outside the application directory.
- Install only one asset matching the system; do not refresh subscriptions on first launch.
- Compare with the baseline before restoring automatic updates and ordinary use.
If the new build opens with an empty list, exit it before writing anything. Identify the paths actually used by the old and new processes, then choose either the built-in import or one complete verified snapshot. Mixing an index generated by one version with isolated YAML files from another can create duplicate entries, missing overrides, or references to files that do not exist.
Verify version, core, data, and proxy behavior before cleaning old files
On first launch, open About or the version page and confirm that the application number matches the selected Release. Record whether the interface shows Clash Party or a transitional label. Then inspect the core version, profile list, policy groups, and logs. The newer name alone does not prove a completed migration, and one remaining old label does not necessarily prove a bad installation. Traceable identity, intact data, and working behavior matter more.
- Application: version, platform architecture, and chosen Release asset agree.
- Data: profiles, overrides, mode, and important preferences are present.
- Core: it starts and remains running without a crash loop.
- Proxy path: a fixed node in rule mode produces an explainable connection.
- Rollback: the old application and private data backup remain available.
If the updater still says Mihomo Party, inspect the repository and version it requests rather than trusting or rejecting the text alone. Apply the same rule to a dialog that says Clash Party: verify the target URL. Branding is one visual clue; organization, repository, tag, asset, and digest form the useful source chain.
Cleanup threshold: complete a close-and-reopen cycle, reload the configuration, and make one practical connection. Keep the backup for an observation period, then remove duplicate installers or an abandoned test directory only when rollback is no longer needed.
A precise way to explain the transition is “the project formerly known as Mihomo Party now uses the Clash Party name,” followed by the official repository link. Do not describe the two transitional filename families as separate official clients, and do not promise that future Releases will retain the old prefix. Asset policy must be checked per Release.
Official sources and version scope
Version numbers, filenames, and interface labels can change. Confirm them in the linked project documentation before making changes.