GlobalProtect on Mac Connects at Login: How to Change It

You open the Mac and GlobalProtect is already connected, or it reconnects every time you sign in. Nothing in the app asks you first. The setting that causes this lives in the portal's agent configuration, not in your user account, and it is not stored in a file you are meant to edit. What you are seeing is the user-logon connect method doing its job.

Knowing which method is assigned tells you what you can change and what you have to request.

The symptom points at policy

The portal's agent configuration decides when GlobalProtect connects, and the two methods you are choosing between are On-Demand, which waits for you, and User-logon (Always On), which connects after sign-in. A portal can also offer Pre-logon (Always On) on supported managed devices, which is out of scope on a Mac you sign into yourself. A machine that connects on its own is almost always on user-logon. The app's own preferences may display the state, but they do not own it, which is why unchecking something in the client does not survive the next policy refresh. The portal pushes the method when you connect and again at every refresh, so a client-side change is temporary by design.

Policy wins, every time.

The two methods, side by side

On-Demand, which the app may still label manual, means you click connect and nothing connects before that. User-logon means the tunnel comes up after you authenticate to the Mac, which is what most managed fleets want, because it removes the window where someone browses unprotected. The trade-off is exactly the symptom you noticed: the tunnel exists before you decided you wanted it. Neither method changes what the tunnel is allowed to reach; they only decide when it comes up.

If your work needs an On-Demand connection, that is a policy change request, not a preference change.

If the goal is a temporary disconnect

Some deployments expose a Disconnect control in the app, and Palo Alto Networks documents it in the Mac Disconnect guide for app version 6.0 and later. It only appears when the agent configuration permits it. That configuration can also require a reason, a passcode or a help-desk ticket, and it can limit how long or how often you stay disconnected.

Complete that workflow instead of stopping the service. Stopping it looks like a disconnect and behaves like a policy violation.

Disconnecting an enforced tunnel also puts your traffic back on the ordinary network path, which is worth remembering while you debug a captive portal.

What editing the launch agent breaks

The usual workaround is editing the launch agent's RunAtLoad or KeepAlive keys, or a private portal preference, to stop the app starting. It can appear to work until the next policy refresh or app update. The app and its managed policy then disagree, which produces a state support cannot reason about. It also leaves the machine in a configuration the organisation never approved.

Hiding a startup window is a different request again, and it has its own supported interface preference.

What to ask for, precisely

Ask for On-Demand by name, or an approved Disconnect workflow with its conditions, or a supported way to suppress the login window. Vague requests get answered with the wrong one, and then you are back to editing plists. Mention the app version you run as well, because the Disconnect control is documented only from 6.0 onward.

If the Disconnect option is missing or the app reconnects immediately, take the assigned agent configuration to IT and ask which method applies to your group.