What Changes in Agents 0.41 to 0.43
October 17, 2026 · InfraScout Team
Three agent releases, 0.41.0 through 0.43.0, are rolling out together. Most of what they change needs nothing from you. Two changes may need action before you update. If a Linux agent hosts MCP servers for InfraScout, check its allowlist and the files its servers run from. And revoking an agent now cuts it off at once and for good, so check how you recover a host before you revoke one.
Before You Update: Agent-Hosted MCP Servers
Agent 0.41.0 adds two requirements for MCP servers an agent hosts. Both apply only to Linux agents with hosting turned on. Every other agent is unaffected.
Check hosting agents before they take 0.41.0
A hosted server reached over plain HTTP on the host's loopback address now needs its own allowed-urls entry, and a Linux stdio server must run from files the agent trusts. A registration that misses either rule fails to start after the update, with the reason in last_error.
The first rule covers remote servers and OAuth bridge legs that use http://127.0.0.1:… or http://[::1]:…. The agent now dials such an address only when the host's allowed-urls list names it. An empty list still admits any https:// address, as before. Without the entry, the registration fails with plain-http loopback url needs an explicit allowed_urls entry. set allowed-urls replaces the whole list, so copy the current entries from mcp-proxy status first, then add the loopback address:
# Note the current allowed_urls entries
sudo agent mcp-proxy status
# Write them back, plus the loopback server
sudo agent mcp-proxy set allowed-urls https://mcp.internal/,http://127.0.0.1:8000/The second rule covers servers the agent launches as a child process. The program and its working directory must be owned by root or by the agent's own account, and neither may be writable by the group or by others. Every directory above them must be owned by root or the agent's account and must not be writable by others, unless it has the sticky bit. Root-owned, group-writable directories such as /usr/local on Debian are fine.
In practice, root-owned launchers such as /usr/bin/npx, /usr/bin/uvx and anything in /usr/local/bin keep working, as do container engines and files owned by a least-privilege service account. Two common setups are now refused: a working directory of /tmp, and an nvm, Homebrew-on-Linux or pipx tree owned by a person's account. Move the server into a root-owned location, or one the agent's account owns, and the next start succeeds. mcp-proxy status shows the reason for any refusal in the server's last_error.
One more change is visible only in the log. An agent with the OAuth bridge on and an empty allowed-urls list now logs a warning when it loads its configuration. It still starts, but the warning is a reminder to narrow the list.
Revoking an Agent Is Immediate and Final
When you revoke an agent's certificate from its details in Agents (Admin), the revocation takes effect at once and everywhere. The agent is disconnected, and it stops receiving commands and other work straight away.
Revocation applies to the agent, not to one certificate, and it is permanent for that agent ID. To bring the host back, delete the revoked agent in the portal and enroll the host again. The same applies to an agent you delete: an agent without an enrollment record cannot connect, so a deleted agent must be enrolled again.
A Revoked Agent Goes Quiet
From agent 0.42.0, an agent that learns its certificate is revoked stops retrying every minute. It logs one error, then checks again only about every six hours, and contacts nothing else in between.
agent service status says what happened and what to do:
Connection: refused — certificate revoked (since …); re-enroll the agent, then restart its serviceRe-enroll the host, then restart its service, and the agent comes back on its next start. enroll auto --force installs and starts the service for you. Token enroll does not, so follow it with agent service restart.
The same quiet state applies to a deleted agent, and to a cloned VM or a VM restored from a snapshot. Once the original host has renewed its certificate, the copy's certificate is superseded, and the copy goes quiet the same way. Enroll the copy as an agent of its own if you want to keep it, then delete the agent record it leaves behind.
Encode Reserved Characters in Proxy Variables
If an agent service gets its proxy from an HTTPS_PROXY or HTTP_PROXY environment variable and the user name or password contains reserved characters, those characters must be percent-encoded: # as %23, ? as %3F, / as %2F, % as %25 and @ as %40. From agent 0.42.0, an agent finds a value that does not parse cleanly and refuses to use it. Its connections then fail with proxy: the HTTPS_PROXY/HTTP_PROXY value did not parse cleanly, so it is not used and its address is withheld. agent proxy status prints the same reminder about which characters to encode. Fix the value, then restart the service.
A proxy that needs credentials is better set on the agent itself, with agent proxy set and agent proxy set-password, which keeps the password protected in the configuration rather than in the service's environment.
The LDAP Bind Password Can Come From the Environment
Enrollment doesn't need LDAP. But enroll and enroll auto also write the agent's configuration, and their optional --ldap-* options let you set up an LDAP bind account, for example on a domain controller, in the same step. From agent 0.43.0, those options can take the bind password from the INFRASCOUT_LDAP_BIND_PASSWORD environment variable instead of --ldap-bind-password, the same way the proxy password comes from INFRASCOUT_PROXY_PASSWORD. The agent clears the variable as soon as it reads it. The variable is used only together with --ldap-bind-dn, so a leftover variable on a host that doesn't use LDAP has no effect. --ldap-bind-password still works and wins if you set both.
enroll auto also now prints the Entra app, tenant and scope it signs you in to, and the InfraScout server that named them, before it asks for a device code. Check those lines before you complete the sign-in: if you mistyped --api, this is where you see it.
Configuration Commands Find the Service's Configuration
Hosts enrolled before the default configuration directory existed keep their configuration beside the agent binary. On those hosts, agent proxy, agent config set, agent ldap and agent mcp-proxy used to fail unless you passed --config. From agent 0.43.0, when you give neither --config nor AGENT_CONFIG and the default file does not exist, these commands use the configuration the installed service runs with. They print one line naming both paths, so you always know which file you edited. A host whose configuration is at the default path behaves exactly as before.
Least Privilege Needs a Configuration Directory of Its Own
On Linux, service set-account --tier gives the configuration directory to the service account's group. From agent 0.43.0, it refuses a directory that holds anything other than the agent's own files. It names up to five of the other files, tells you to move them out or give the agent a directory of its own such as /etc/infrascout, and changes nothing. The standard install already meets this rule.
Run the Linux Agent Without Root →
Limits on Command Output and WMI Queries
From agent 0.41.0, shell and PowerShell output is capped at 3 MiB per stream, and WMI queries return at most 10,000 rows. WMI refuses classes that walk the whole file system and Win32_Product, and answers "WMI is busy" while earlier timed-out queries are still finishing. From 0.43.0, a command that times out on Windows ends its whole process tree, not just the shell that started it. The Agents tool reference covers each limit.
Fixes and Improvements
Re-enrolling a Windows host that has already run the agent, with agent enroll auto --force, now gives you a working agent on the first try (0.43.0).
Agent Command Reference
Every command and flag the agent accepts, including MCP hosting, proxy and service control.