Troubleshooting

Every problem below is one we have actually hit, on a real machine, and the cause is stated rather than guessed. If your symptom is not here, the logs are the next stop — the last section says where they are.

My terminal cannot reach the internet, but my browser is fine

The most important entry on this page, and the most confusing symptom.

What you see: claude, codex, pip, npm, curl all fail with ECONNREFUSED or a connection error. Browsers work perfectly.

Why: AariaSec routes command-line tools by setting HTTPS_PROXY and friends. Browsers use their own proxy settings and ignore those variables — hence the split. If AariaSec is not running but the variables are still set, every proxy-honouring tool dials a port nothing is listening on.

Fix — Windows:

reg query HKCU\Environment | Select-String 'PROXY|CERT|CA_'

If that prints values while AariaSec is not running, clear them. Newer builds do this automatically at logon; if yours does not, quit AariaSec from the tray, which clears them properly.

If you used the machine-wide installer (the one that asked for administrator rights), the variables live in a different place and the command above will print nothing at all — which looks like an all-clear when it is not. Check the machine hive too, from an elevated prompt:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" |
 Select-String 'PROXY|CERT|CA_'

Fix — macOS / Linux: the variables are session-scoped and disappear when you log out. Quitting AariaSec clears them immediately.

The root cause is worth understanding: on Windows these variables live in the registry and survive reboots by design. So a force-quit — Task Manager, a crash, a power cut — could leave routing armed with nothing behind it, indefinitely. Current builds install a logon task that clears stale routing whenever the proxy is not listening.

HTTPS fails with a certificate error after I cleared the proxy

A trap worth knowing before it bites you.

AariaSec sets six variables, not two. Alongside HTTPS_PROXY and HTTP_PROXY there are SSL_CERT_FILE, REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS and NO_PROXY.

SSL_CERT_FILE replaces the trust store rather than extending it, and it points at a bundle containing the AariaSec CA. So if you clear only the proxy pair and leave that one set, Python and Node go straight to the real internet and then reject every genuine certificate, because the only CA they trust is ours.

Clear all six, or none:

foreach ($v in 'HTTPS_PROXY','HTTP_PROXY','NO_PROXY','SSL_CERT_FILE','REQUESTS_CA_BUNDLE','NODE_EXTRA_CA_CERTS') {
 Remove-Item "Env:\$v" -ErrorAction SilentlyContinue
}

Use Remove-Item, not $env:X = "". An empty value still counts as set to many clients, which fails differently and more confusingly.

I clicked launch and nothing happened

Almost always the cold start, not a failure. The first launch takes one to three minutes and the app is windowed, so there is no console and no progress bar until the dashboard opens.

Do not launch it again while waiting. On older builds a second launch during startup began a second full stack, producing two windows that blocked each other. Current builds hold a mutex from process start: a second launch raises the first window and flashes its taskbar button instead.

If several minutes pass with nothing, check the log — see the last section.

There is no tray icon

Windows 11 hides new tray icons by default. Click the ^ chevron next to the clock; the shield is in the overflow flyout. This accounts for nearly every report.

If it is genuinely absent, the log will say why — look for a line naming a module that could not be imported. That indicates a packaging problem in that build rather than anything wrong with your machine.

The tray shows no colour for alerts

On macOS the menu-bar item shows a coloured status indicator beside the shield. Windows has no equivalent affordance, so status appears in the tooltip — hover the shield and you will see AariaSec - 3 critical, - 2 alerts, or - OK.

Two windows are open and they disagree

One shows your edition, the other does not; one looks stale.

Each window loads independently, so a window opened before you activated a licence keeps showing pre-activation state until it reloads. Press Ctrl-R (or Cmd-R) in the older window. Both windows are the same stack — you are not running two copies. To confirm:

Get-Process aariasec -ErrorAction SilentlyContinue

One process means one instance.

winget fails with a certificate error

This one is not AariaSec, despite appearing at the same time.

winget reads Windows' own proxy configuration, which AariaSec does not touch — we only set environment variables, and winget ignores those. It also pins its source certificates, so it rejects any intercepting proxy regardless of trust.

Try:

winget source reset --force
winget source update

Stale source metadata is the usual cause.

No events appear even though an agent is running

Check in this order:

1. Is monitoring armed? The dashboard says so explicitly. Discovery finding an app is not the same as routing its traffic.
2. Is the CA trusted? Routing is refused without it, by design.
3. Is that endpoint one we know? Only known LLM endpoints are inspected. An agent talking to a private inference server needs that host added.
4. Did the agent start before monitoring did? Environment variables reach processes started afterwards. Restart the agent.

Where the logs are

launcher.log is the first thing to read for any Windows problem: it records why the tray, the window or the proxy did not come up. Earlier builds discarded that output entirely, which is why some of the problems above took so long to diagnose.

No log contains prompt or response text. Content is reduced to a SHA-256 fingerprint at capture, so there is nothing sensitive to redact before sharing a log with us.