Cisco Secure Client on Mac: window, auto connect or reconnect?

Something Cisco-related appears after you log in, and it may or may not be connecting anything. The window, the automatic connection and the reconnect after a network change are three separate behaviours with three separate owners. Most frustrated attempts to remove a launch item begin with those three collapsed into one complaint. Sort them out first and the change request writes itself.

Name the behaviour you are actually seeing

Watch one login without touching anything and write down what happens, in order. A window that opens with no connection is one case, a window that opens and connects is another, and a connection that returns after the network changes is a third. Ask what actually establishes the tunnel rather than what appears on screen, because the window and the tunnel have different owners. Two kinds of evidence answer that, and only one of them sees this client:

scutil --nc list
ps aux | grep -i [v]pnagentd
ifconfig | grep -A3 utun

Read the three outputs together, because scutil --nc list lists the system's VPN configurations and an empty list only means no system VPN service owns a tunnel. Cisco Secure Client does not register one: it terminates through vpnagentd and a utun interface, so the process and the interface are the evidence that sees it. When vpnagentd is running and a utun interface holds an address, the tunnel exists even with the window closed; when neither is present, the automatic connection is off and the window is the only thing to discuss. The front end can also run while a separate background service owns the tunnel, so the ownership question belongs to the profile sections rather than to this one.

The window at login is a launch question

A login window comes from a launch agent or from the application's own open-at-login preference, and neither is the same mechanism as connection policy. Identify the installed product and version before editing anything, because documentation for older releases describes files a current installation may not use. Turning off the automatic connection does not necessarily stop the window from opening, and stopping the window does not stop a reconnect. Use the client's supported startup control or your administrator's software process, in that order.

On a managed Mac, confirm whether the behaviour arrives through an installed configuration profile before treating it as a local preference. The system can list the profiles it has, and a managed login item is not yours to delete:

profiles show -type configuration

Where the setting is user-controllable, change it in the client preferences and log out to test. Where it is locked, the profile owner is the only person who can change it. Removing files locally produces a divergence that the next update silently repairs, which makes it the least durable fix available. A greyed-out checkbox is not a broken client; it is a policy statement.

Auto Connect on Start is a separate preference

Cisco's connection guide names Auto Connect on Start as the preference that controls a connection attempt when the client launches, and describes it as off by default. A deployed profile can enable it, which is why two Macs with the same client behave differently at login. Look for that preference in the client's settings before assuming anything about launch items.

Change it through the supported control and test with a full logout rather than a relaunch, because some components only start with the login session. Then confirm the manual connection still works, since a preference that suppresses the automatic attempt should not remove your ability to connect. If the client reconnects immediately anyway, you are looking at the reconnect behaviour instead. That is the next question, and it has a different owner.

Auto Reconnect belongs to a third setting

Reconnect governs what happens after an established session loses its path: a lid closing, a Wi-Fi network changing, a wired link dropping. Cisco documents it separately from startup behaviour, so a startup change will not touch it. Test it by disconnecting the network for a moment and watching whether the tunnel returns without input.

A reconnect that ignores a deliberate disconnect is usually policy rather than a bug. Some deployments require an always-on arrangement, which belongs in a policy conversation instead of a workaround. Removing the component that enforces it may break posture checks and then be restored by the next management push. If the requirement is legitimate, ask what it is meant to guarantee and whether a narrower setting satisfies it; if it is not, the profile owner can change it in one place rather than you changing it on forty laptops.

Ask for the smallest change, then verify it

Write the request with four facts: which client build you run, which macOS build you run, what appears after a login, and whether a tunnel forms without input. Then state the desired outcome in one sentence a colleague could implement without asking you. Keeping the client available but closing its window is a different request from preventing an automatic connection. A precise request gets a policy change, while a vague one gets a workaround that nobody owns.

After the change, log out and back in, then run the manual connection workflow you depend on. If reconnect was in scope, test that separately under whatever procedure your administrator permits.

Check that the security modules the organisation requires are still running, since a silent removal is easy to miss until an audit finds it. The result you want is the requested startup behaviour with a working client, not an absent icon and a mystery. Write down which of the three behaviours changed, so the next person can tell a real fix from a coincidence.