# ch34xser_macos ships the WCH USB-to-serial driver for macOS

> This repository is the macOS distribution point for the WCH USB-to-SERIAL driver: the CH34xVCPDriver package and disk image, an installation guide that covers the Intel and Apple silicon paths separately, and the manual steps for approving the kernel extension in System Preferences. It is a binary release rather than a source project, and the licence is not recorded.

**WCHSoftGroup/ch34xser_macos** — MacOS USB driver for USB to serial chip ch340, ch341, ch342, ch343, ch344, ch9101, ch9102, ch9103, etc

- Repository: https://github.com/WCHSoftGroup/ch34xser_macos
- Stars: 550 · Forks: 36
- Language: Unknown
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/wchsoftgroup-ch34xser-macos

## What this repository actually contains

This installation guide document shows the procedure of installing the macOS driver for the WCH USB-to-Serial devices, and the driver can be downloaded from the website, at the link http://www.wch.cn/downloads/CH341SER_MAC_ZIP.html.

The top-level entries show what kind of repository this is. There is CH34xVCPDriver.dmg, CH34xVCPDriver.pkg, a PDF called CH34X_DRV_INSTAL_INSTRUCTIONS.pdf, the README.md and a README.assets/ directory holding the screenshots the guide refers to.

So this is a binary distribution point, not a source tree. There is no C source, no build system, no test suite and no contribution model for the driver itself. The primary language is recorded as unknown for the same reason, and the licence is not recorded either. What the repository provides is the packaged installer in both of its formats, the visual guide and the written instructions.

That matters for anyone deciding how to use it. The vendor's website is where the download link points, and this repository is the accompanying documentation and a copy of the artifacts, which is why the README's own installation step 1 is to download the driver from the website and unzip the file to a local installation directory.

The images in the README.assets directory are not decoration either. Each installation step in the guide points at a specific screenshot, numbered one through nine, so the guide is written to be followed with a picture of what you should be looking at on screen. That is a reasonable choice for a procedure that involves a System Preferences approval, which is easy to get wrong on a first attempt.

## Which chips are supported

The chip model support list is split into two groups, and the split is by the number of serial ports rather than by family.

The first group covers USB to Single Serial Port: CH340, CH341, CH343, CH346, CH339, CH9101, CH9102, CH9111, CH9143, CH9149 and CH9433.

The second covers USB to Multi Serial Ports: CH342, CH344, CH346, CH347, CH9103, CH9104, CH9105 and CH9114.

CH346 appears in both lists, which suggests the part can be configured either way depending on how it is strapped, and the repository description names a slightly different set, the ch340, ch341, ch342, ch343, ch344, ch9101, ch9102, ch9103 chips among others.

The practical significance of the grouping is that a multi-port chip needs more than one device node to appear. The verification step at the end of the guide expects a tty.wchusbserialx node, where x is the assigned device number similar to Windows COM port assignment, and with a multi-port chip you would expect several of them.

The naming is worth a moment because it explains what you are looking for in the terminal. The driver exposes its devices under the tty.wchusbserial prefix rather than the cu.usbserial names that macOS assigns to FTDI chips, which is the fastest way to tell a WCH device from an FTDI one when both are plugged in.

The driver download itself is hosted by the vendor rather than built from this repository, so the version you install is whatever is current on the WCH download page at the time you fetch it.

## Installing on Big Sur and later, and on older systems

The installation procedure branches on the macOS version, and step 2 is where the branch happens.

When using OS X 11.0 and above and the OS does not support Rosetta, the dmg format driver should be installed, following step 4. Otherwise the pkg format driver should be installed by default, following step 3.

The Rosetta mention is the interesting part. On Apple silicon, a driver built as an Intel-only kernel extension cannot be loaded, and the way the vendor handles that is to ship a separate disk image version that is native, while the pkg installer covers the Intel case where Rosetta translation can stand in.

The pkg route is the straightforward one. When installing the pkg format driver, click on the driver file and continue to proceed step by step.

For macOS 11.0 and above there is an extra operation regardless of which installer you used. Open LaunchPad and find the CH34xVCPDriver Application, open the App and click the Install button.

For OS X 10.9 to OS X 10.15 the extra step is a restart: click Restart to restart your computer, then perform the following steps after restarting.

The dmg route is a drag and drop. Click the dmg file and drag CH34xVCPDriver into the Application folder in macOS, then open LaunchPad, find the CH34xVCPDriver Application, open it and click the Install button.

So the two paths converge on the same place: a small application whose Install button does the work that older macOS did during the system install itself. The application is not a control panel, and the guide gives no indication that you need to run it again later.

## Verifying it worked, and the approval macOS demands

Two verification steps close the guide, and the first of them is the one that catches a driver that was installed but never approved.

When you plug the USB-to-SERIAL device into the USB port, you can open System Report, then Hardware, then USB. On the right side is the USB Device Tree, and you will find a device whose Vendor ID is 0x1a86 if the USB device is working properly.

That vendor ID is the WCH identifier, and checking it in System Report separates two different failures. If the device appears with the right vendor ID but no driver, the hardware and the USB connection are fine and the problem is the driver. If the device does not appear at all, the problem is upstream of the driver entirely.

The second step confirms the driver has bound a device node. Open the Terminal program under the Applications-Utilities folder and type:

```bash
ls /dev/tty*
```

You should see the tty.wchusbserialx where x is the assigned device number, similar to Windows COM port assignment.

Then there is the approval step, and the README is emphatic about it because it is the most common reason a working driver appears not to work. Mac OS High Sierra 10.13 introduces a new feature that requires the user's approval before loading new third-party kernel extensions. Go to System Preferences, Security and Privacy, and click Allow.

The more specific instruction is to go to the General page under Security and Privacy, and below the title Allow apps downloaded from: choose the choice 2, Mac App Store and identified developers, so that driver will work normally.

For OS X 11.0 and above the README states that with the upgrade of macOS versions, the authorization method has changed, and points to the corresponding screenshots for the version you are on. That change is the reason the guide is versioned at all.

## Uninstalling, and what it says about the design

The uninstall instructions are split three ways by macOS version, and the differences between them are informative about how the driver is installed on each.

For OS X 10.9 to 10.11, two commands in Terminal:

```bash
sudo rm -rf /Library/Extensions/CH34xVCPDriver.kext
```

For OS X 10.12 to 10.15 the same first command appears, along with a second kext to remove:

```bash
sudo rm -rf /Library/Extensions/CH34xVCPControlDriver.kext
```

The kext extension lives in /Library/Extensions, and the receipts are the installer bookkeeping that pkg writes, which have to be removed as well or the installer will think the driver is still present. The wildcard on the receipts path is what catches the versioned subdirectory that pkg creates.

For OS X 11.0 and above the process is entirely different: remove the Application to Trash to uninstall, and restart the computer again before reinstalling the driver.

That last instruction is the clearest statement of the design shift. On a modern macOS the driver is installed by an application rather than by writing a kext into a system directory with an installer package, so removing it means removing the application. The restart requirement suggests the extension is loaded and unloaded on a reboot rather than on demand.

The whole picture is of a driver whose installation model had to change twice in a decade: a pkg install with a system extension on older systems, and an application-based install on newer ones, with an approval step in between.

## Where this driver fits, and where it stops

The comparison worth making is with the FTDI driver that macOS ships with, and with the newer serial drivers that do not need a kernel extension at all.

Against the built-in FTDI driver, the difference is that macOS has a driver for FTDI chips in the box and has nothing for WCH chips, which is why this installer exists at all. The vendor ID check in the guide is the practical way to tell which family you have, and if your adapter enumerates as an FTDI device the system driver may already be enough. Many WCH-based adapters are sold with a CH340 chip specifically because it is cheap, and they are common in Arduino boards, in serial debug adapters and in a lot of laboratory equipment.

Against the newer approach, the direction of travel is away from kernel extensions. A kext has to be signed, has to be approved by the user, and has to be trusted by the operating system's security model, and each of those steps is friction. The modern pattern is a user-space driver built on the DriverKit or on the newer serial support in the system, which needs no approval at all. The vendor's own instruction to allow identified developers is the visible cost of the older model.

The limits are worth naming. The system requirement line is written as OS X 10.9 to OS X 10.15 and OS X 11.0 (Big Sur) and above, so the guide covers the Intel and the Apple silicon eras separately, and the two paths install differently. The installation is not scripted in a way a package manager can consume, so it is a manual procedure with a System Preferences step and, on older systems, a restart. And because this repository is the packaging and documentation rather than the source, a user who wants to know what the driver actually does, or to build it, has to go elsewhere.

The documentation is thorough for what it is. The guide covers both installers, both approval paths, a hardware-level check, a device-level check and a removal procedure for three OS ranges, with a screenshot at each step.

The last push was on 2026-09-11 and the repository is not archived, with no GitHub releases, so the packaged files in the repository root are updated in place.

## Conclusion

ch34xser_macos suits a macOS user with a WCH USB-to-serial adapter who cannot see the device, since the guide covers the two installer formats, the approval step macOS requires for third-party kernel extensions, and how to confirm the driver loaded by looking for the vendor ID and the device node. It is the wrong tool if you need to build or inspect the driver, because this repository holds the packaged installer and the guide rather than the source, and the README directs you to the vendor website for the download. Before you install, read the Note section about the security settings, since a driver that does not load because it was never approved in System Preferences looks exactly like a driver that is broken.

## FAQ

### What is ch34xser_macos?

It is the macOS distribution point for the WCH USB-to-SERIAL driver, the CH34xVCPDriver. The repository holds the packaged installer in both a pkg and a dmg form, a PDF of the installation instructions and the README, and the primary language and licence are not recorded because the driver itself is not built from this repository.

### Which WCH chips does this macOS driver support?

The single serial port parts are CH340, CH341, CH343, CH346, CH339, CH9101, CH9102, CH9111, CH9143, CH9149 and CH9433, and the multi serial port parts are CH342, CH344, CH346, CH347, CH9103, CH9104, CH9105 and CH9114. The driver download itself is hosted at the WCH website.

### How do I install the driver on macOS Big Sur or later?

On a system without Rosetta support, install the dmg format driver: click the dmg file, drag CH34xVCPDriver into the Application folder, then open LaunchPad, find the CH34xVCPDriver Application and click the Install button. Otherwise the pkg format driver is installed by default, and the same application Install step applies on OS X 11.0 and above.

### How do I check whether the driver loaded correctly?

Open System Report, then Hardware and USB, and look in the USB Device Tree for a device whose Vendor ID is 0x1a86. Then open Terminal and run ls /dev/tty*, where you should see a tty.wchusbserialx node with x the assigned device number.

### Why does the driver not work until I approve it in System Preferences?

Mac OS High Sierra 10.13 introduced a requirement for the user's approval before loading new third-party kernel extensions. The README says to go to System Preferences, Security and Privacy, General, and below Allow apps downloaded from: choose Mac App Store and identified developers. On OS X 11.0 and above the authorization method has changed and the README points at the version-specific screenshots.

### How do I uninstall the WCH driver on macOS?

On OS X 10.9 to 10.15 remove the kext and the installer receipts from Terminal with sudo rm -rf on /Library/Extensions/CH34xVCPDriver.kext and the matching paths under /var/db/receipts, plus CH34xVCPControlDriver.kext on 10.12 and above. On OS X 11.0 and above you move the application to Trash and restart the computer before reinstalling.

## Sources

- [Issues](https://github.com/WCHSoftGroup/ch34xser_macos/issues)
- [README](https://github.com/WCHSoftGroup/ch34xser_macos/blob/main/README.md)
- [WCHSoftGroup/ch34xser_macos on GitHub](https://github.com/WCHSoftGroup/ch34xser_macos)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wchsoftgroup-ch34xser-macos