Split Tunnel Still Excludes an App You Uninstalled

The old app is gone, and the split-tunnel list still has an entry for it. Nothing visibly breaks, which is why it stays there for months. Then someone installs a different program into the same folder, or a managed profile restores the rule at every reconnect, and traffic starts taking a path nobody planned. The exclusion outlived the reason for it.

Cleaning this up is mostly about identity: what the rule points at now, and who owns the list.

The symptom: an exclusion that matches nothing

A stale entry is invisible in normal use. It becomes visible in three ways: an application you expected to be tunneled goes direct, a new program inherits an old exception, or the client refuses to save an edit because the managed profile overwrites it. All three look like separate bugs, and all three are the same bookkeeping problem. Each one is cheap to check and expensive to misdiagnose.

Start by reading the rule, not by deleting it.

Find out what the rule identifies

Split-tunnel implementations key exclusions on different things: an executable path, a package name, a bundle identifier or a route. A path-based rule points at a file that may no longer exist, or may now be a different file. A package-based rule points at an identity a new install can reuse. Read the client's documentation for the field you are looking at, because the same text box means different things across products. Android's VpnService guide is the reference for the package-based case.

The display name is the least reliable part of the entry, and it is the part people read.

Path rules and package rules behave differently

A path rule that survives an uninstall usually becomes inert, and inert is the good outcome. The bad outcome is a path that gets reused, because the new executable silently inherits the exception. Package rules behave differently again: a product may ignore an unavailable package, reject it, or keep matching by name when something new claims that name.

Do not port an assumption from one client to another. Check what yours actually does with a missing target, ideally by creating the condition deliberately on a test machine and watching which process inherits the exception.

Remove it through the owner

If the list comes from a managed profile, editing it locally is a temporary change that will be restored at the next reconnect. Change the profile, or ask whoever owns it, and confirm the edit survives a reconnect. If the list is local, remove the entry and check that the client rewrote its configuration rather than keeping the old one in memory.

An empty list is not the goal. A list whose entries still match real requirements is.

Test both directions afterwards

After cleanup, test an app that should still be excluded and an app that should now be tunneled. Confirm DNS behaviour separately, because resolver policy is a different control from the exclusion list. Then reconnect once and re-test, since a restored profile is the most common way a cleanup quietly undoes itself.

Keep a one-line purpose next to every remaining exception. That line is what stops the list from becoming a museum, and it makes the next cleanup a five-minute job.