# Setting the Mac hostname so plain claude starts in personal

Canonical page: https://convos.rob-knight.com/setting-the-mac-hostname-so-plain-claude-starts-in-personal-f5cd72bc
Published: 2026-10-11

- Session: 9 Oct 2026, 08:30 to 08:41 UTC
- Project: chat-personal
- Agent: Claude Code
- Model: claude-opus-5-5
- Tags: claude-code, macos, hostname, launcher-troubleshooting, shell-config, mac-housekeeping
- Value: 3.0 · of 4
- Time: 2m · active
- Elapsed: 11m · wall-clock span
- Commits: 0 · from this session
- Cost: $1.00 · model spend
- Tokens: 2k · uncached in, plus out
- Tool calls: 6 · by the agent
- Outcomes: 3 · 3 left open

## Summary

Get plain `claude` running in the personal context on this Mac, which was failing with 'unknown native claude machine'.

Rob reported that running `claude` on this Mac failed with 'unknown native claude machine' when it should have used the personal context. The agent traced the shell function to a native launcher script that identifies the machine from the short hostname, and it accepts only two specific names. The Mac had no explicit HostName set, so the network-derived name was used, which matched neither accepted name. The agent proposed setting the HostName to MBP16 with sudo, which Rob had to run himself, and suggested fixing the source template rather than only the installed copy. A follow-up check reported that the short hostname now returned MBP16 and that the native launcher's version command ran past the machine check.

## What came out of it

- Diagnosed the cause: no HostName was set on this Mac, so the network-derived short hostname (MacBook-Pro) failed the launcher's machine check.
- Set the Mac HostName to MBP16 with sudo scutil, run by Rob, per the agent's instructions.
- Verification run reported `hostname -s` returning MBP16 and the native launcher's --version printing 2.1.295 without the machine-check error.

## Left open

- The source launcher template in the agents install-launchers script was not edited; the agent recommended fixing it so the next publish does not overwrite the change, but this was not done in the session.
- Other launchers or hooks that use the same hostname check were not audited.
- The trigger that caused the network hostname to be picked up was only suspected (DHCP or reverse DNS) and was not confirmed.

Running `claude` on this Mac kept failing with 'unknown native claude machine', even though it should have opened my personal context. The error came from the native launcher that the shell function calls, so I had the agent trace it through.

The launcher works out which machine it is on from the short hostname, and it only accepts two specific names. This Mac had no hostname set explicitly, so macOS was filling one in from the network. That name matched neither accepted value, so the launcher stopped before Claude started. The computer name and local hostname were still set to the expected name, which is why it wasn't obvious at first.

The fix was to set the hostname explicitly so the network can't override it. That step needs admin rights, so I ran it myself. Afterwards the short hostname came back as the expected name, and the launcher's version check got past the machine check. Shells that were already open still held the old function, but it calls the same script, so they work too.

I also considered editing the launcher directly. The same check lives in the template that generates the installed copy, though, so a change made only to the installed version would be overwritten the next time the launchers are regenerated, and other scripts using the same check would still break. I haven't made that template change yet, so it's still on the list.

Two things remain open. I suspect a DHCP or reverse DNS name was being picked up and triggered this, but I haven't confirmed it. I also haven't checked the other launchers and hooks that use the same hostname check.