Did the VPN rename your Mac? Compare three hostname values
A changed Terminal prompt is not a rename. ComputerName, LocalHostName and HostName hold different values, and one of them is often simply unset.
The prompt that used to read one thing now reads another, and the connection that changed was a VPN. That is the whole of the evidence most people have before concluding the Mac was renamed, and it is not enough. macOS stores at least three separate name values, each with a different job, and a shell prompt shows at most one of them in a way you can easily misread.
Comparing them takes three commands and settles the question before anybody edits anything.
Three values, three jobs
All three are strings the system will happily report, and the temptation is to treat the first one you find as authoritative. That is how a user ends up "fixing" the wrong field and watching the symptom survive.
| Value | What it is responsible for |
|---|---|
ComputerName | The friendly name a person sees in About and on the network browser; this is the one users mean by "my Mac's name" |
LocalHostName | The Bonjour name used on the local link, usually shown with a .local suffix in Sharing |
HostName | An explicitly configured host name that may simply not be set at all |
The third row is where most confusion starts. An unset HostName is a normal state, not corruption, and it means the system falls back to other sources when it needs a host name. Reading that emptiness as damage leads to a fix that was never needed. It also hides the real question, which is not what the machine is called but which name a given lookup or prompt is using at that moment. Answer that, and the empty value stops looking like a fault.
Read before you write
These three commands only report values. They do not change anything, which makes them safe to run during an investigation.
scutil --get ComputerName
scutil --get LocalHostName
scutil --get HostNameRun them in the same local session before and after an allowed VPN connection, and note which value actually differs. If nothing differs and the prompt still looks wrong, the name was never the problem: something in the shell configuration or the remote session is displaying a different string.
Apple's guide to computer names and local hostnames places the friendly name under General and About, and the local name under General and Sharing. It also documents the automatic suffix added when another Mac on the same link already uses a name, which is worth knowing before you treat an unexpected number as proof of tampering.
What a shell prompt actually proves
A prompt is a string the shell builds, and its hostname element may come from the expanded host name, a shortened form of it, or a value hard-coded in a profile file. It can also belong to an SSH session on a completely different machine, which is the least glamorous explanation and by far the most common one for a prompt that changed the moment you connected a VPN.
Check where you are before you check what you are called. Run hostname and compare it with the three stored values, then look at the shell's prompt setting to see whether it displays the host at all. If the prompt contains a literal string somebody typed into a configuration file years ago, no system change will ever make it match.
The comparison matters for reporting too. A prompt that looks different and a stored ComputerName that genuinely changed are two findings with two different owners, and merging them into one sentence sends the next engineer looking in the wrong place.
Where a VPN can legitimately touch naming
A VPN changes which resolvers and search domains are relevant, and it can hand the client a host name through DHCP if the client is configured to accept one. That is a real mechanism, and it is also narrower than "the VPN renamed my Mac". A resolver changing which name resolves for a given address does not rewrite the stored local values.
So separate two questions. Is the machine's own identity different, or is the name it uses to reach something else different? The first is answered by the three stored values; the second is answered by DNS lookups and by the connection profile in use. Treating them as the same question produces changes to identity settings in response to a name resolution problem.
If a permanent hostname really is required
Setting a value is a deliberate administrative action, not a cosmetic preference, and the value should come from whoever owns the machine's naming policy. Overwriting a managed name so a prompt looks familiar can break certificate checks, monitoring and anything else that identifies the host.
Where the change is genuinely required, the same tool that read the values writes them, and HostName accepts a fully qualified name while the other two expect the local forms. Record what you changed and why, because this is exactly the kind of edit that surprises the next person to look at the machine.
For most reports the correct answer is smaller than the question suggests: read all three values, identify which one differs, and fix only that. The prompt was a symptom of something, and the three commands tell you which something.