Fresh install gives a 401 when the client/agent tries to reach the server.

[Scott8586]

Running v6.5.0. I tried to do a fresh agent install on a new machine (a raspi4b, not a proxmox client). Nothing special, followed the standard procedure for installing a linux agent (well, the new process, cut'n'paste the code to install, then paste In the token, seemed to work correctly). I didn't see any error on installation, but I don't see it show up on the server, and the client log show the following once a minute:

Oct 09 22:05:55 vsl-exp-pi4b pulse-agent[35858]: {"level":"warn","component":"remote_config_client","action":"agent_lookup_non_success_status","endpoint_url":"http://192.168.32.188:7655/api/agents/agent/lookup?hostname=vsl-exp-pi4b","hostname":"vsl-exp-pi4b","status_code":401,"status":"401 Unauthorized","time":"2026-10-09T22:05:55-07:00","message":"Remote config agent lookup returned non-success status"}
Oct 09 22:05:55 vsl-exp-pi4b pulse-agent[35858]: {"level":"warn","error":"resolve agent ID: agent lookup responded with status 401 Unauthorized","component":"remote_config","action":"refresh_failed","time":"2026-10-09T22:05:55-07:00","message":"Failed to refresh remote config"}

Is there something different about the inclusion of a new agent in 6.5.0? Where should I look next?

[pulse-triage[bot]]

The silent token prompt in 6.5.0 does not change Linux-agent reporting permissions; lookup HTTP 401 is an authentication rejection, whereas a missing reporting scope returns 403. Does the existing agent log also contain Pulse rejected this agent's API token from host reporting, or only the remote_config errors (share only the redacted error line if present)? That separates a rejected service credential from a config-only startup fault; keep the token and installation unchanged for now.

How Pulse handles triage

[Scott8586]

This is the full startup message. Per your instructions, I have not rerun the install yet, however previous to posting I had run install twice in case I had made some kind of cut'n'paste mistake:

Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"warn","component":"startup","action":"tls_skip_verify_enabled","time":"2026-10-10T06:21:55-07:00","message":"TLS verification disabled for agent connections (self-signed cert mode)"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"info","path":"/var/lib/pulse-agent/agent-id","agentID":"90068e81-xxxxxxx","time":"2026-10-10T06:21:55-07:00","message":"Loaded persisted agent ID"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"warn","component":"remote_config_client","action":"agent_lookup_non_success_status","endpoint_url":"http://192.168.32.188:7655/api/agents/agent/lookup?hostname=vsl-exp-pi4b","hostname":"vsl-exp-pi4b","status_code":401,"status":"401 Unauthorized","time":"2026-10-10T06:21:55-07:00","message":"Remote config agent lookup returned non-success status"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"warn","error":"resolve agent ID: agent lookup responded with status 401 Unauthorized","component":"remote_config","action":"fetch_failed","time":"2026-10-10T06:21:55-07:00","message":"Failed to fetch remote config - using local (or previously cached) defaults"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"info","version":"v6.5.0","pulse_url":"http://192.168.32.188:7655","observer_destinations":0,"host_enabled":true,"docker_enabled":false,"kubernetes_enabled":false,"proxmox_mode":false,"auto_update":true,"time":"2026-10-10T06:21:55-07:00","message":"Starting Pulse Unified Agent"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"info","component":"health_server","action":"listening","addr":"127.0.0.1:9191","time":"2026-10-10T06:21:55-07:00","message":"Health/metrics server listening"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"info","time":"2026-10-10T06:21:55-07:00","message":"Command execution disabled (use --enable-commands to enable)"}
Oct 10 06:21:55 vsl-exp-pi4b pulse-agent[37052]: {"level":"info","time":"2026-10-10T06:21:55-07:00","message":"Host agent module started"}
Oct 10 06:21:56 vsl-exp-pi4b pulse-agent[37052]: {"level":"error","component":"agent","endpoint":"/api/agents/agent/report","status_code":401,"pulse_url":"http://192.168.32.188:7655","time":"2026-10-10T06:21:56-07:00","message":"Pulse rejected this agent's API token (401 Unauthorized). The token is no longer valid on the server, which usually means Pulse was restored/reinstalled or upgraded (for example v5 -> v6) without carrying the token across. Re-run the agent install command from the Pulse UI to mint a fresh token. Reports are dropped until the token is replaced."}

[pulse-triage[bot]]

Host reporting also gets 401, so this is not a lookup-only fault; the log's restore/upgrade explanation is generic, not an established cause here. In the Pulse instance the agent targets, open Settings → API Access in the Security group: is the token used for this Pi listed, and does Last used say Never or show recent activity? Those observations distinguish a missing record from a token-use mismatch; leave the installation and credentials unchanged, and do not post the token, its hint or service files.

How Pulse handles triage

[Scott8586]

The token for this pi is not in the Token Inventory.

[Scott8586]

I was mistaken - the token is there with a "never" used. The only agent is docker reporting.

[pulse-triage[bot]]

On the same Pulse instance, open Settings → Infrastructure → Install on a host, generate one token with a distinct name and leave command execution disabled. Before running the installer, reopen Settings → API Access and refresh it: does that named record appear and remain? Keep the new token private and the Pi unchanged for now; this checks server registration before another installation could use it.

How Pulse handles triage

[Scott8586]

Yes, it's there, the only scope selected is docker monitoring.

[pulse-triage[bot]]

Your host-enabled Pi needs Agent reporting (agent:report) and Agent config fetch (agent:config:read); Docker reporting alone is insufficient. Missing scope returns 403 after authentication, so it does not explain the recorded 401s—leave the Pi and tokens unchanged. Was that Docker-only record generated under Infrastructure → Install on a host, or API Access → Create token (the host-install generator supplies both scopes automatically)?

How Pulse handles triage

[Scott8586]

It was created under infrastructure -> install on a host. My mistake, it does include agent:config:read, and agent:report, I didn't scroll down far enough.

[Scott8586]

It was created under infrastructure -> install on a host. My mistake, it does include agent:config:read, and agent:report, I didn't scroll down far enough.

[pulse-triage[bot]]

Those are the correct host-reporting scopes, so no permission change is needed. Is the Never used entry the token last entered on the Pi before this report, or the later token we asked you to generate without installing it? Never is expected for the later token and would not explain the running service’s 401s; leave the Pi and both tokens unchanged, and do not post their values or hints.

How Pulse handles triage

[Scott8586]

Both the original (where I "installed" it), and the recently created token show "never"

[pulse-triage[bot]]

PULSE_TOKEN in the service environment or an explicit --token argument can take precedence over the installer’s private token file in 6.5.0. Is either configured for pulse-agent on this Pi (yes/no/unknown only; do not paste service or environment contents)? That distinguishes a credential override from the file hand-off; leave the installation and tokens unchanged.

How Pulse handles triage

[Scott8586]

No, only '--token-file' is set, both in connection.env, and in the pulse-agent.service. The file is the standard /var/lib/pulse-agent/token

[pulse-triage[bot]]

With no override, 6.5.0 reads the token file as a bare value; it does not interpret quotes or a PULSE_TOKEN= prefix. Without editing it, privately check whether it contains just the token or includes quotes/a prefix, and reply only bare, quoted, prefixed or unknown—not its contents or hint. This distinguishes file formatting from a different credential or server record; leave the installation and tokens unchanged.

How Pulse handles triage

[Scott8586]

Bare

[pulse-triage[bot]]

That rules out an override and file formatting. Was the original token generated through the exact Pulse address already shown in the Pi's startup log (same, different or unknown only), so we can distinguish address routing from a credential mismatch? Different addresses can still reach the same instance; leave the Pi and both tokens unchanged and do not post addresses, token values or service files.

How Pulse handles triage

[Scott8586]

same

[pulse-triage[bot]]

With the same address, the next distinction is whether the saved credential belongs to the record you inspected. Privately compare the first six and last four characters of the existing token file with the original Pi record's Hint in API Access, and reply only match, different or unknown—a match is only a partial check, not proof of full equality. Do not share either value or hint, edit the file, or change the Pi or tokens.

How Pulse handles triage

[Scott8586]

match

[pulse-triage[bot]]

The hint match covers only the token’s ends; a bare file can still contain missing characters or embedded whitespace. The host-install generator produces one 64-character lowercase hexadecimal value: does the existing file have that shape, allowing surrounding whitespace (yes, no or unknown only)? Check privately without printing, editing or sharing the value or hint, and leave the installation and tokens unchanged.

How Pulse handles triage

[Scott8586]

no, there was a duplication of some characters. Thanks for the help - I'll know where to look next time