CliDeck
WORKSPACE

macOS Serial Port Names Explained: `/dev/cu.*` vs `/dev/tty.*` (and which one to use)

← Back to Blog

Quick answer

  • For almost every serial console task on macOS (routers, switches, firewalls, UART debug, microcontrollers), use: /dev/cu.*
  • /dev/tty.* is used less often, for “incoming line” semantics and specific cases where the open behavior matters.

If you have no internet or you’re on a clean Mac with no extra tools installed, using cu + /dev/cu.* is one of the most reliable offline options. And if you want a better workflow for multiple devices, organized session history and logs, and browser access, that’s exactly where CliDeck fits: CliDeck Workspace.

Why macOS shows two device names for one serial port

When you connect a USB-to-Serial adapter, macOS often creates two device nodes that look almost identical:

  • /dev/cu.usbserial-XXXX
  • /dev/tty.usbserial-XXXX

This does not mean you have “two different ports.” It’s the same underlying serial line exposed via two access styles:

  • cu is the “callout” device (think: “outgoing connection,” open the port now)
  • tty is the “dial-in / call-in” device (think: “incoming line,” where open behavior may differ)

In real-world terms, the rule is simple: if you’re initiating an interactive console session yourself, use /dev/cu.*.

Which one should you use: /dev/cu.* or /dev/tty.*

Use /dev/cu.* almost always

/dev/cu.* is the best default for:

  • console access to network gear (Cisco/Juniper/Arista, etc.)
  • USB-Serial adapters (FTDI/CP210x/CH340 and similar)
  • UART debug on boards and embedded devices
  • any scenario where you want to connect, see output, and type commands

Practical reason: /dev/cu.* typically opens immediately and predictably, without “waiting” behavior.

Use /dev/tty.* only if you know you need it

/dev/tty.* makes sense in rarer scenarios where you need “incoming line” behavior (for example, when a service or a specific workflow treats the port as an inbound terminal line).

If you’re unsure, it’s probably not your case.

Comparison table

Topic/dev/cu.*/dev/tty.*
Typical purpose“Connect now”“Incoming line / special open behavior”
Best for serial console sessionsYes (default)Usually no
Chance of confusing behavior in day-to-day useLowerHigher
RecommendationUse in almost all casesUse only when required

How to find the “right” port on macOS

1) List all callout ports (usually what you want)

ls -1 /dev/cu.*

2) List all dial-in ports

ls -1 /dev/tty.*

3) The most reliable method: diff before/after

ls -1 /dev/cu.* > /tmp/cu_before.txt
# plug in the adapter
ls -1 /dev/cu.* > /tmp/cu_after.txt
diff /tmp/cu_before.txt /tmp/cu_after.txt

The line that appears is your port.

Common port name examples (what you might see)

In practice you’ll often see:

  • /dev/cu.usbserial-*
  • /dev/cu.SLAB_USBtoUART
  • /dev/cu.wchusbserial*
  • /dev/cu.usbmodem*

The rule doesn’t change: use the /dev/cu.* version, not the matching /dev/tty.*.

How to use the selected port (two common approaches)

Option A: cu (built-in)

Example for 9600 baud (a very common default for network console ports):

cu -l /dev/cu.usbserial-XXXX -s 9600

Exit cu safely:

  • press Enter (so ~ is the first character on the line),
  • then type ~.

Option B: screen

screen /dev/cu.usbserial-XXXX 9600

If you use screen, the same device rule applies: /dev/cu.*.

Why it can feel like the port is “stuck” (and the fast fix)

If you chose /dev/tty.* and the session feels odd (slow to open, no output, “hung” behavior), switch to the matching /dev/cu.*.

Quick checklist:

  1. Make sure the port exists:
ls -1 /dev/cu.*
  1. Make sure nothing else is using it:
  • close IDE serial monitors and any other terminal sessions that might hold the port
  1. Try the two most common baud rates:
cu -l /dev/cu.usbserial-XXXX -s 9600
cu -l /dev/cu.usbserial-XXXX -s 115200
  1. If you see garbled characters, it’s almost always a baud rate mismatch.

Where CliDeck helps (and why it complements cu)

cu is a great choice when you need to connect quickly, locally, and offline to a single device. But as soon as your workflow grows beyond “connect and exit,” you usually miss three things:

  • multiple devices and sessions in one place (without juggling dozens of terminal windows)
  • history and logs (so output isn’t lost and can be reviewed later)
  • browser access and a team-friendly workflow

That’s exactly why we build CliDeck: CliDeck Features.

Mini FAQ

Why do I have both /dev/cu.* and /dev/tty.*?

Because macOS exposes two access styles to the same serial line: “callout” and “dial-in.” For everyday console work, you almost always want callout.

Which one should I use for routers/switches/Arduino?

/dev/cu.*.

Can I break anything by opening /dev/tty.*?

Usually not. But you can waste time troubleshooting confusing behavior. Using /dev/cu.* avoids that in most cases.

Bottom line

If you’re initiating a serial console session from a Mac, use /dev/cu.*. It’s the most practical and predictable option.

And when you need more than “connect and exit” (multiple devices, session history, logs, browser access), try CliDeck: CliDeck Workspace.