Tämä on vanhempi versio. Uusin versio on 0.3.3. Axiopera 0.3.3 · Julkaistu:
Asennustiedostot 0.3.2
| Arkkitehtuuri | Tyyppi | Laajuus | Tiedostokoko | Lataus | SHA256 |
|---|---|---|---|---|---|
| 64-bittinen | ZIP → Portable | — | — | github.com | VirusTotal |
Linkki ja SHA256-tiiviste ovat peräisin Windows Package Managerin yhteisön manifestista. Vertaa ladatun tiedoston tiivistettä ennen kuin suoritat sen.
Muutosloki
Fixed
- macOS: inside an agent's sandbox, such as Claude Code's command sandbox, axiopera no longer starts the daemon and asks you to re-run the command outside the sandbox. A daemon started there stayed in the sandbox, passed it on to every sub-agent, and gave them the sandbox's network proxy settings.
- Windows: a process in the Codex sandbox can no longer add an instance of the daemon's named pipe and receive other clients' requests, including the environment that spawn sends. Clients also refuse a pipe served by a sandboxed process.
- If the data directory is read-only or not writable, axiopera asks you to re-run the command outside the agent sandbox instead of reporting only the system error.
- Linux: axiopera top no longer misses a task update that the daemon saves within a few milliseconds of the previous one.
Other notes
- Sub-agents can no longer run axiopera daemon stop, skill install or plugin cleanup; run them from the main session or a terminal. Version-mismatch errors shown to sub-agents no longer suggest daemon stop --force.
- On Linux the client does not check whether it runs in a sandbox. With Grok's --sandbox workspace and a data directory the sandbox can write, it can still start the daemon inside the sandbox.
- Stop the daemon with axiopera daemon stop before replacing the executable.
- Updating the Codex plugin may require trusting it again.
