Does not install, something wrong?
Downloading plugin plugin: installing: unraid-aicliagents.plg Executing hook script: CA_preHook Clearing Community Applications plugin cache Executing hook script: pre_plugin_checks plugin: downloading: repair-plugin.sh ... plugin: repair-plugin.sh download failure: Invalid URL / Server error response Executing hook script: CA_postHook Clearing Community Applications plugin cache Executing hook script: post_plugin_checks Plugin installed

On 8/23/2026 at 9:07 PM, irso said:

Hallo, thank for the plugin, works like a charm.

Is it possible to add openai compatible API endpoint. if i have suscription thru openrouter?


Thanks

Hi, so you can configure each agents as per their feature set as defined in their documentation. Most can use a model behind an openAI compatible end point, they are typically configured with environment variables. You can set these for each agent (e.g. Claude, Codex, OpenCode etc.) in the settings for all workspace/sessions, or set them for a specific workspace on the main tab.

Is this what you meant?

2 hours ago, Cirion said:

Does not install, something wrong?
Downloading plugin plugin: installing: unraid-aicliagents.plg Executing hook script: CA_preHook Clearing Community Applications plugin cache Executing hook script: pre_plugin_checks plugin: downloading: repair-plugin.sh ... plugin: repair-plugin.sh download failure: Invalid URL / Server error response Executing hook script: CA_postHook Clearing Community Applications plugin cache Executing hook script: post_plugin_checks Plugin installed

hi, can i check, are you installing from the CA App Store, or from the link in the first post in this thread?

10 minutes ago, johner said:

hi, can i check, are you installing from the CA App Store, or from the link in the first post in this thread?

From the ca app store, and I did a retry now and it seems like it is installing, at least it is working a lot more...

On 8/31/2026 at 8:47 PM, Cirion said:

From the ca app store, and I did a retry now and it seems like it is installing, at least it is working a lot more...

Ok great, maybe github had a brainfart? i uninstalled and reinstalled - all fine to. Let me know if it happens again, maybe I can add some better logging

ENOENT: no such file or directory, mkdir '/tmp/unraid-aicliagents/work/root/home/.cache/opencode/bin'

path: "/tmp/unraid-aicliagents/work/root/home/.cache/opencode/bin",

syscall: "mkdir",

errno: -2,

code: "ENOENT"

Bun v1.3.14 (Linux x64 baseline)

[Agent Exited Immediately] The agent exited after 0s — likely missing configuration.

Press ENTER to retry, or close this workspace from the UI.

this happens when i start the second workspace.

On 9/13/2026 at 2:26 AM, Uliphant said:

ENOENT: no such file or directory, mkdir '/tmp/unraid-aicliagents/work/root/home/.cache/opencode/bin'

path: "/tmp/unraid-aicliagents/work/root/home/.cache/opencode/bin",

syscall: "mkdir",

errno: -2,

code: "ENOENT"

Bun v1.3.14 (Linux x64 baseline)

[Agent Exited Immediately] The agent exited after 0s — likely missing configuration.

Press ENTER to retry, or close this workspace from the UI.

this happens when i start the second workspace.

thanks for reporting, would you mind testing in the latest version please?

On 9/15/2026 at 6:39 AM, johner said:

thanks for reporting, would you mind testing in the latest version please?

Now it crashes unraid server. Uninstall. Something crazy happening with the workspace. I did manage to move it off usb in settings. Also, what’s up already having relay enabled with a key?

On 9/15/2026 at 6:39 AM, johner said:

thanks for reporting, would you mind testing in the latest version please?

Had similar serious issues....

1. Broken onboarding requests

2. A stale relay listener

3. Incorrect/empty workspace browsing

4. JavaScript initial-load failures

5. Unraid’s terminal launcher breaking only on the AICliAgents page

6. Finally, the entire server becoming unreachable

so a couple things, worth noting, if your Unraid host still boots off USB, the default settings are to install both the home and agents to a path on the USB, so any activity to bulk writ will be slow, such as agent upgrades, on home area consolidation. You can move these else where, ideally not on the array if you want it to function with the array offline - try an unassigned drive (see that plugin). I have added more onine feedback of status updates on home/agent activity (better progress tracking), that'll be available once I finish testing this new version.

Also, I noticed agents that perform certain hard hitting commands against the \mnt\user paths it can block Unraids merged file system, this is a limitation of Unraid's fs as I understand it, abd so far I have a rule/memory line to tell the agent to use the underlying paths, such as \mnt\cache, or to be less aggressive with the find, grep etc.

I might need some further context from you both, but let me see if claude can find anything suspicious in the code given the commentary.

Thanks for being patient!

On 9/18/2026 at 7:28 AM, pmyoung said:

Had similar serious issues....

1. Broken onboarding requests

2. A stale relay listener

3. Incorrect/empty workspace browsing

4. JavaScript initial-load failures

5. Unraid’s terminal launcher breaking only on the AICliAgents page

6. Finally, the entire server becoming unreachable

> Thanks for reporting this

>

> The confirmed problems are:

>

> - the Relay listener can survive an upgrade while still running old plugin code;

> - Relay currently enables its external listener/key path too eagerly;

> - workspace browsing can perform large directory scans through /mnt/user; (which can expose the Unraid shfs fuser hang issue I can't work around on Array style shares)

> - agent workspaces also default to /mnt/user, which can put heavy filesystem pressure on Unraid’s user-share layer.

>

> Those last two are plausible contributors to the host becoming unreachable, although I cannot prove that from the report alone. I am treating them as high-priority stability work.

>

> To identify the remaining reports, could you please provide:

>

> 1. Plugin version, Unraid version, browser and browser version.

> 2. For onboarding or JavaScript failures: the first browser Dev Tools Console error/stack and any failed Network request.

> 3. For the terminal issue: which terminal is affected — the normal Unraid top-bar terminal, the AICliAgents terminal, or creating a new workspace — plus a screenshot/error and whether it works from the Dashboard in the same browser session.

>

> 4. If the server becomes unreachable again, please do not deliberately repeat it. After recovery, send the approximate time, Unraid Diagnostics, and /boot/logs/syslog-previous if available.

>

> That will let me separate browser/UI failures from the host-level filesystem issue and add targeted regression coverage

On 9/17/2026 at 1:26 AM, Uliphant said:

Now it crashes unraid server. Uninstall. Something crazy happening with the workspace. I did manage to move it off usb in settings. Also, what’s up already having relay enabled with a key?

> Thanks

>

> ENOENT: no such file or directory, mkdir

> /tmp/unraid-aicliagents/work/root/home/.cache/opencode/bin

>

> The current launcher already creates the required parent cache directory before OpenCode starts, so this is unlikely to be a simple missing-directory fix. It suggests either a timing race, a managed-home remount/sync occurring during launch, or an older launcher generation still being used.

>

> Before trying again, could you please provide:

>

> 1. The exact plugin and OpenCode versions.

> 2. Whether both workspaces use OpenCode, and whether they use different workspace folders.

> 3. Your configured agent-home/storage location — default, USB, pool, array, or Unassigned Device.

> 4. Whether a backup, home consolidation, plugin upgrade, or storage-location change was happening around the same time.

> 5. The relevant timestamp and debug-log lines covering the first workspace launch and the failed second launch.

> 6. Whether pressing Enter to retry succeeds after the first workspace is closed.

>

> Please avoid repeatedly retrying if the server becomes unstable. The report that the host became unreachable after moving storage off USB is being treated as a separate host-stability concern

Hi,

I performed a fresh install on Unraid 7.3.2 from the app store, tested claude and codex, chrome and safari (both mac), all seems ok. Let me know if you were able to get more diagnostics.

Thanks

John

I’d like external agents to hand tasks to workspaces on my Unraid box through Agent Relay, using a thin external bridge connected as a Relay remote, without maintaining a plugin fork or adding another task store.

What stops me today. A remote can only read its inbox, list contacts and send direct messages (RelayMcpTools::EXTERNAL_TOOLS). DMs seem deliberately wrong for this: recipients are told to treat their contents as untrusted data rather than instructions, and DMs have no request lifecycle or cancellation.

What I actually want to use is the existing relay_request mechanism: a request to a topic’s assigned actor, with its pending → acknowledged → resolved/failed/timed_out lifecycle and actor auto-launch. As far as I can tell from the current source, remotes can’t use it.

The narrow ask: could an administrator grant a specific remote permission to call relay_request and relay_request_status for specific topics? For example, this could be configured on the remote’s row under Settings → Agent Relay and default to disabled.

That seems to preserve Relay’s existing trust model:

• The assigned actor remains the only workspace allowed to act on the request, and it still decides what to do.

• The administrator explicitly decides which remote can submit requests to which topics.

• Direct messages remain untrusted and unchanged.

• The existing request file remains the authoritative record; an external bridge doesn’t need its own task database.

• Topics provide stable external targets even when the workspace/session assigned as actor changes.

My immediate use case is an A2A bridge: an A2A task could map directly to a Relay request ID and map the Relay request lifecycle onto A2A task states. But the proposed permission isn’t A2A-specific; it would just expose the existing actionable-request primitive to explicitly trusted remotes.

Two optional follow-ups would make that integration more complete, but aren’t necessary for the basic use case:

1. Sender-side cancellation (relay_cancel_request, or similar), with a cancelled state visible to the actor.

2. Per-token rather than per-IP rate limiting, since multiple remote identities behind one bridge host currently share the same 30/minute budget.

I’m happy to test this against a pre-release and can sketch the grant data shape if useful. I’d also be interested if there’s a constraint in the Relay design or the remote-client ADR that makes exposing requests to authorized remotes undesirable; there may be context that isn’t visible from the public repository.

43 minutes ago, protagonista said:

I’d like external agents to hand tasks to workspaces on my Unraid box through Agent Relay, using a thin external bridge connected as a Relay remote, without maintaining a plugin fork or adding another task store.

What stops me today. A remote can only read its inbox, list contacts and send direct messages (RelayMcpTools::EXTERNAL_TOOLS). DMs seem deliberately wrong for this: recipients are told to treat their contents as untrusted data rather than instructions, and DMs have no request lifecycle or cancellation.

What I actually want to use is the existing relay_request mechanism: a request to a topic’s assigned actor, with its pending → acknowledged → resolved/failed/timed_out lifecycle and actor auto-launch. As far as I can tell from the current source, remotes can’t use it.

The narrow ask: could an administrator grant a specific remote permission to call relay_request and relay_request_status for specific topics? For example, this could be configured on the remote’s row under Settings → Agent Relay and default to disabled.

That seems to preserve Relay’s existing trust model:

• The assigned actor remains the only workspace allowed to act on the request, and it still decides what to do.

• The administrator explicitly decides which remote can submit requests to which topics.

• Direct messages remain untrusted and unchanged.

• The existing request file remains the authoritative record; an external bridge doesn’t need its own task database.

• Topics provide stable external targets even when the workspace/session assigned as actor changes.

My immediate use case is an A2A bridge: an A2A task could map directly to a Relay request ID and map the Relay request lifecycle onto A2A task states. But the proposed permission isn’t A2A-specific; it would just expose the existing actionable-request primitive to explicitly trusted remotes.

Two optional follow-ups would make that integration more complete, but aren’t necessary for the basic use case:

1. Sender-side cancellation (relay_cancel_request, or similar), with a cancelled state visible to the actor.

2. Per-token rather than per-IP rate limiting, since multiple remote identities behind one bridge host currently share the same 30/minute budget.

I’m happy to test this against a pre-release and can sketch the grant data shape if useful. I’d also be interested if there’s a constraint in the Relay design or the remote-client ADR that makes exposing requests to authorized remotes undesirable; there may be context that isn’t visible from the public repository.

Hi, I was dipping the toes into this as I didn't want to open people up to security risks by rushing in, I think this would be useful. I have a few defects to fix, I'll then focus on this idea - thank you!

Subject: antigravity-cli — install/update always produces an empty package (binary missing), traced to two bugs in the consolidate pipeline

Diagnosis and workaround below were prepared with Claude Code (Anthropic's CLI agent), running on this box under the aicliagents plugin itself — it traced the failure through the plugin's own logs and source rather than me guessing.

Plugin version: 2026.09.15.08

Agent affected: antigravity-cli (curl_install source)

Symptom: After updating or reinstalling antigravity-cli via the Store card, the workspace fails to launch with:

[Agent Binary Missing] The agent binary was not found.

Expected: .../agents/.versions/antigravity-cli/agent_antigravity-cli_consolidated_.../home/.local/bin/agy

What was found (via lifecycle.log / debug.log and reading the plugin source):

1. Side-by-side install runs for a curl_install agent, which AgentHandler.php itself documents as unsupported. AgentHandler::sideBySideInstallBlocker() (includes/handlers/AgentHandler.php:253) explicitly states curl_install agents aren't ready for side-by-side installs because their vendor script "lands its binary inside a captive home directory inside the agent's own tree." Despite that, lifecycle.log shows an antigravity-cli upgrade going side-by-side anyway:

[MOUNT] Agent antigravity-cli: generation ...0001... is still in use — installing

...0002... alongside it (no session closed).

2. The real breakage: consolidate_layers's pre-bake mount refresh wipes the writable layer before packaging it. In src/scripts/storage/storage_ops.sh, the block labeled WP #1246 remounts the overlay ("refresh... before reading the merged view") right before mksquashfs runs. For antigravity-cli, this refresh was confirmed to empty the writable (zram) upper directory: the real agy binary was manually installed (via Google's own https://antigravity.google/cli/install.sh, HOME/PREFIX pointed at the live generation dir) and verified working (agy --version → 1.2.8, 207MB on disk). Running the plugin's own install-bg.php afterward (which re-invokes consolidate_layers) baked a new squashfs at 4096 bytes — i.e. it discarded the populated upper dir and shipped an empty layer, same as every prior attempt. Confirmed via atomic_write_layer log lines (bytes=4096) on every one of 3 separate install attempts across two plugin versions (1.2.4 upgrade, 1.2.8 fresh install, 1.2.8 re-consolidate).

Trace IDs for reference: 938fcf06 (upgrade attempt), d1918f1e (fresh install attempt).

Impact: Every install/update of antigravity-cli on this system has produced an unusable agent since upgrading to 2026.09.15.08. A workaround (running the vendor install script by hand into the live mount, without letting the plugin's own consolidate re-run) gets it working again, but it only lives in the RAM-backed overlay and is wiped on reboot or the next Store-card action that triggers consolidate.

Ask: Could someone check storage_ops.sh's WP #1246 pre-consolidate refresh path for curl_install-sourced agents (or specifically agents that were side-by-side-installed) — it looks like the refresh isn't preserving the correct upper dir before mksquashfs runs.

---

Root-cause tracing and the working-again fix above were done end-to-end by Claude Code — reading lifecycle.log/debug.log, walking through AgentHandler.php/CurlInstallSource.php/storage_ops.sh, and reproducing the byte-for-byte empty-package result three times before landing on the actual mechanism. Happy to have it dig further if a maintainer wants more specific repro data.

Just the human here wanting to say that I really enjoy this plugin so thanks!

Matt

UPDATE: (2026-09-27): This just reproduced again on a real update — not just my own reinstall testing. I updated antigravity-cli through the Store card as usual (not manually), and it hit the identical failure: lifecycle.log shows the same signature (old_size_mb: 0 → a 4096-byte consolidated .sqsh), this time on generation agent_antigravity-cli_consolidated_0000000005_20260926T231458Z, going from 1.2.8 → the then-latest 1.2.11:

2026-09-26T23:14:48Z | installer | agent_install_target_resolved | {"agent":"antigravity-cli",...,"version":"1.2.11","fallback":false,"explicit":true}

2026-09-26T23:14:57Z | StorageMountService | consolidate_start | {"type":"agent","id":"antigravity-cli","old_size_mb":0}

2026-09-26T23:14:59Z | atomic_write_layer | atomic_write_ok | {...,"final":"agent_antigravity-cli_consolidated_0000000005_20260926T231458Z.sqsh","bytes":4096}

So this is now confirmed across 5 separate installs (2 plugin versions, 2 antigravity-cli target versions, both explicit-version and "latest" upgrade paths) — it's not something specific to how I was triggering it initially. Every single install/update of antigravity-cli since the 2026-09-17 plugin upgrade has produced an empty package on this system.

Reapplied the same manual workaround (installing the real vendor binary directly into the live generation mount, without letting the plugin's consolidate step touch it) and it's working again (agy 1.2.12).

Update (2026-09-28): Confirmed and fixed for good — not just patched in RAM this time. Had Antigravity run the actual repair itself, using the exact fix it identified: it called the plugin's own atomic_write_layer() function, but passed it agent_mount_real("antigravity-cli") (the already-resolved real directory) instead of the buggy symlink path the plugin's own op_consolidate normally uses.

Result — verified independently on my end too:

- New persisted layer: agent_antigravity-cli_consolidated_0000000006_20260927T212043Z.sqsh, 45,555,712 bytes (vs. the previous 4,096-byte empty dummy)

- unsquashfs -l confirms it actually contains home/.local/bin/agy, VERSION, and the full directory tree — a real package this time

- Plugin's own storagectl.sh status reports "outcome":"ok", "mounted":true, layer registered correctly in layer_manifest.json with checksum

- Old broken 4KB layer was cleanly removed

So antigravity-cli is now genuinely working and should survive a reboot — this was hand-applied outside the Store UI (since the UI's own install/update path still has the underlying bug), but it proves the one-line fix works cleanly with zero side effects on the plugin's own manifest/mount bookkeeping.

tl;dr for whoever picks this up: storage_ops.sh line ~1600 just needs $MNT_POINT swapped for $_MOUNT_POINT_REAL (or the equivalent agent_mount_real "$ID" call) before it's handed to atomic_write_layer. Everything downstream of that already works correctly once it's given a real path instead of a symlink.

Edited September 27Sep 27 by fatredwombat1

I see there is an option for GitHub copilot but how do you link it to your account? There’s only a spot for an api key but GitHub copilot doesn’t offer an api key to link to your account as far as I’m aware.

9 hours ago, Android_18 said:

I see there is an option for GitHub copilot but how do you link it to your account? There’s only a spot for an api key but GitHub copilot doesn’t offer an api key to link to your account as far as I’m aware.

Hi,

When you start the agent in a workspace, type /login, you'll then get a menu of options:

Is this what you meant?

Thanks

John

On 9/23/2026 at 11:20 AM, fatredwombat1 said:

Subject: antigravity-cli — install/update always produces an empty package (binary missing), traced to two bugs in the consolidate pipeline

Diagnosis and workaround below were prepared with Claude Code (Anthropic's CLI agent), running on this box under the aicliagents plugin itself — it traced the failure through the plugin's own logs and source rather than me guessing.

Plugin version: 2026.09.15.08

Agent affected: antigravity-cli (curl_install source)

Symptom: After updating or reinstalling antigravity-cli via the Store card, the workspace fails to launch with:

[Agent Binary Missing] The agent binary was not found.

Expected: .../agents/.versions/antigravity-cli/agent_antigravity-cli_consolidated_.../home/.local/bin/agy

What was found (via lifecycle.log / debug.log and reading the plugin source):

1. Side-by-side install runs for a curl_install agent, which AgentHandler.php itself documents as unsupported. AgentHandler::sideBySideInstallBlocker() (includes/handlers/AgentHandler.php:253) explicitly states curl_install agents aren't ready for side-by-side installs because their vendor script "lands its binary inside a captive home directory inside the agent's own tree." Despite that, lifecycle.log shows an antigravity-cli upgrade going side-by-side anyway:

[MOUNT] Agent antigravity-cli: generation ...0001... is still in use — installing

...0002... alongside it (no session closed).

2. The real breakage: consolidate_layers's pre-bake mount refresh wipes the writable layer before packaging it. In src/scripts/storage/storage_ops.sh, the block labeled WP #1246 remounts the overlay ("refresh... before reading the merged view") right before mksquashfs runs. For antigravity-cli, this refresh was confirmed to empty the writable (zram) upper directory: the real agy binary was manually installed (via Google's own https://antigravity.google/cli/install.sh, HOME/PREFIX pointed at the live generation dir) and verified working (agy --version → 1.2.8, 207MB on disk). Running the plugin's own install-bg.php afterward (which re-invokes consolidate_layers) baked a new squashfs at 4096 bytes — i.e. it discarded the populated upper dir and shipped an empty layer, same as every prior attempt. Confirmed via atomic_write_layer log lines (bytes=4096) on every one of 3 separate install attempts across two plugin versions (1.2.4 upgrade, 1.2.8 fresh install, 1.2.8 re-consolidate).

Trace IDs for reference: 938fcf06 (upgrade attempt), d1918f1e (fresh install attempt).

Impact: Every install/update of antigravity-cli on this system has produced an unusable agent since upgrading to 2026.09.15.08. A workaround (running the vendor install script by hand into the live mount, without letting the plugin's own consolidate re-run) gets it working again, but it only lives in the RAM-backed overlay and is wiped on reboot or the next Store-card action that triggers consolidate.

Ask: Could someone check storage_ops.sh's WP #1246 pre-consolidate refresh path for curl_install-sourced agents (or specifically agents that were side-by-side-installed) — it looks like the refresh isn't preserving the correct upper dir before mksquashfs runs.

---

Root-cause tracing and the working-again fix above were done end-to-end by Claude Code — reading lifecycle.log/debug.log, walking through AgentHandler.php/CurlInstallSource.php/storage_ops.sh, and reproducing the byte-for-byte empty-package result three times before landing on the actual mechanism. Happy to have it dig further if a maintainer wants more specific repro data.

Just the human here wanting to say that I really enjoy this plugin so thanks!

Matt

UPDATE: (2026-09-27): This just reproduced again on a real update — not just my own reinstall testing. I updated antigravity-cli through the Store card as usual (not manually), and it hit the identical failure: lifecycle.log shows the same signature (old_size_mb: 0 → a 4096-byte consolidated .sqsh), this time on generation agent_antigravity-cli_consolidated_0000000005_20260926T231458Z, going from 1.2.8 → the then-latest 1.2.11:

2026-09-26T23:14:48Z | installer | agent_install_target_resolved | {"agent":"antigravity-cli",...,"version":"1.2.11","fallback":false,"explicit":true}

2026-09-26T23:14:57Z | StorageMountService | consolidate_start | {"type":"agent","id":"antigravity-cli","old_size_mb":0}

2026-09-26T23:14:59Z | atomic_write_layer | atomic_write_ok | {...,"final":"agent_antigravity-cli_consolidated_0000000005_20260926T231458Z.sqsh","bytes":4096}

So this is now confirmed across 5 separate installs (2 plugin versions, 2 antigravity-cli target versions, both explicit-version and "latest" upgrade paths) — it's not something specific to how I was triggering it initially. Every single install/update of antigravity-cli since the 2026-09-17 plugin upgrade has produced an empty package on this system.

Reapplied the same manual workaround (installing the real vendor binary directly into the live generation mount, without letting the plugin's consolidate step touch it) and it's working again (agy 1.2.12).

Update (2026-09-28): Confirmed and fixed for good — not just patched in RAM this time. Had Antigravity run the actual repair itself, using the exact fix it identified: it called the plugin's own atomic_write_layer() function, but passed it agent_mount_real("antigravity-cli") (the already-resolved real directory) instead of the buggy symlink path the plugin's own op_consolidate normally uses.

Result — verified independently on my end too:

- New persisted layer: agent_antigravity-cli_consolidated_0000000006_20260927T212043Z.sqsh, 45,555,712 bytes (vs. the previous 4,096-byte empty dummy)

- unsquashfs -l confirms it actually contains home/.local/bin/agy, VERSION, and the full directory tree — a real package this time

- Plugin's own storagectl.sh status reports "outcome":"ok", "mounted":true, layer registered correctly in layer_manifest.json with checksum

- Old broken 4KB layer was cleanly removed

So antigravity-cli is now genuinely working and should survive a reboot — this was hand-applied outside the Store UI (since the UI's own install/update path still has the underlying bug), but it proves the one-line fix works cleanly with zero side effects on the plugin's own manifest/mount bookkeeping.

tl;dr for whoever picks this up: storage_ops.sh line ~1600 just needs $MNT_POINT swapped for $_MOUNT_POINT_REAL (or the equivalent agent_mount_real "$ID" call) before it's handed to atomic_write_layer. Everything downstream of that already works correctly once it's given a real path instead of a symlink.

Thank you, this is fixed in the next release (shortly - lots of fixes and updates!)

Hi all, thank you for the reports and the patience.

A new release is now in the Community Applications store: version 2026.10.01.04. It also includes the release before it (2026.09.30.04), so if you are still on 2026.09.15.08 you get everything in one update.

Please update soon if you run Unraid 7.3.2. In the old version the home backup step did not write a backup file on that Unraid version. The plugin then refused to merge your home, and every save packed the live database instead. This is fixed. The backup is now written and checked before the plugin uses it.

Other fixes for problems you reported

• Storage on /mnt/user is allowed, but the plugin now advises against it. It also uses the real pool path when the share is set to "cache only".

• A rebuild of the agent layers no longer switches the agent in the middle of the build. A build that would lose the agent program is now refused.

• Cache folders are left out of the compressed layer instead of being deleted from your live home.

• The installer shows its progress lines again.

• A workspace order in the drawer now stays after an update.

• A new workspace waits until it is ready before it loads its terminal.

New

• A workspace can continue by itself after a temporary model error, and you can schedule a Continue for any workspace.

• Voice: you can set up natural voice and local dictation from Settings.

Please tell me if anything still goes wrong after the update. It helps most if you say your Unraid version and which agent you use.

I'm seeing this spammed in my syslog on every page I go to (even if I'm not on the AICLIAGENTS page). Do you know how to fix this error?

Oct 5 10:31:03 webgui: Invalid .page format: plugins/unraid-aicliagents/AICliRelayMcp.page

Edited October 5Oct 5 by bobokun

6 hours ago, bobokun said:

I'm seeing this spammed in my syslog on every page I go to (even if I'm not on the AICLIAGENTS page). Do you know how to fix this error?

Oct 5 10:31:03 webgui: Invalid .page format: plugins/unraid-aicliagents/AICliRelayMcp.page

Hi bobokun, thanks for the report. You found a real fault, and I can see it on my own test server too.
What it is: The plugin has a small web endpoint for linked Relay clients. It was saved as a .page file, but it is not a menu page and has no page header. Unraid reads every .page file whenever it draws a page, so it logged "Invalid .page format" each time. It is harmless, but it fills the system log.
The fix: The endpoint is now a plain PHP file that the plugin loads itself, so Unraid no longer sees it. The update also removes the old file. I checked that the message stops after the update, and Relay linking is not affected.
When: The fix will come with the next update. I'll post here when it is out.
Until then: you can ignore the message, because nothing breaks. If you want the log quiet, you can delete /usr/local/emhttp/plugins/unraid-aicliagents/AICliRelayMcp.page. The message will come back after a reboot or a plugin reinstall, that step on a newer build than the public one, so please only do it if you are comfortable with it.

Thanks again for the clear report.

Hey @johner i have two things regarding the plugin

1. If you dont accept PRs, why do you have it enabled in the first place? If you dont accept or dont want them, atleast disable the feature so people like me dont just waste their time trying to improve this plugin just for you to close the PR without saying anything

2. You should really work on your release pipeline for this plugin. Every commit is made by "AICliAgents Release Publisher" with tens of thousands of lines added and thousands of removed, most of the actual changes are from your src/assets/ui folder where you have like a hundred files that you keep re-commiting just with slightly different names (i assume this has something to do with minification and a terrible release pipeline on your end that ships the files like that although there are no changes as new files). You ship like ten features and bug fixes with a single commit. This all makes it super hard to understand your code base and understand what was added or changed in each of your commits. I do not know who build this for you, even claude (which i assume you use heavily) would never suggest this to you unless you explicitly tell it you want it that way, but you should improve this man....

Edited October 13Oct 13 by Joly0

Hi Tere,

First of all, thanks for this plugin, it is awesome! I use it everyday and I understand it is a work in progress so I wanted to contibute with some ideas as it is very prone to storage failures, crashes and session mishandling. I had to recover multiple times and lost some sessions as they were not baked in time to be persistent. With little help from Ai to analyse the setup construct, here are my suggestions for concideration:

1. Re-register untracked homes automatically. The scheduled-bake and reconcile loops should discover homes from the persistence directory and the config, not only from manifest entities. A home with layers on disk but no manifest entry should get its entity rebuilt on the first supervisor tick, which is what the boot notification already claims happens.

2. Make the manifest survive a bad shutdown. Keep a copy of the manifest on a durable path or inside each baked layer, and rebuild it from the layers when the flash copy is empty or unparsable. Today one lost file silently disables every safety net.

3. Verify every bake after writing. Re-read the delta from flash, check size and the squashfs header, and only then record it. A zero-byte result should be deleted and retried, never left in the directory.

4. Skip or quarantine unmountable layers instead of failing the stack. One empty file should not push the whole home onto tmpfs. Log which layer failed and why.

5. Never report a no-op bake as success. "Skipped, empty" while the home is on the tmpfs fallback, and "busy" with exit code 2, must surface as a warning in the UI, not a green tick.

6. Refuse to run a workspace on the tmpfs fallback without a visible warning. The user should know that everything written in that state will be lost.

7. Default the writable layer to disk when the storage path is durable, and recommend moving storage off the USB stick on first run. RAM-backed homes should be an explicit choice with a clear warning, not the default.

I was also unable to change from ZRAM to disk, the move has failed. "Writable layer = Disk" can never complete on a home that contains any Claude Code transcript, because the post-bake wipe protects .claude/projects/* while the switch demands an empty upper. The switch should treat files proven identical to a baked layer as safe to drop, or move them along with the directory skeleton.

I hope this will help to make it even better!

Edited October 15Oct 15 by Marcin M
Adding more details.

On 10/14/2026 at 9:24 AM, Joly0 said:

Hey @johner i have two things regarding the plugin

1. If you dont accept PRs, why do you have it enabled in the first place? If you dont accept or dont want them, atleast disable the feature so people like me dont just waste their time trying to improve this plugin just for you to close the PR without saying anything

2. You should really work on your release pipeline for this plugin. Every commit is made by "AICliAgents Release Publisher" with tens of thousands of lines added and thousands of removed, most of the actual changes are from your src/assets/ui folder where you have like a hundred files that you keep re-commiting just with slightly different names (i assume this has something to do with minification and a terrible release pipeline on your end that ships the files like that although there are no changes as new files). You ship like ten features and bug fixes with a single commit. This all makes it super hard to understand your code base and understand what was added or changed in each of your commits. I do not know who build this for you, even claude (which i assume you use heavily) would never suggest this to you unless you explicitly tell it you want it that way, but you should improve this man....

Hi @Joly0

Sorry, I do accept, I let Claude and Codex do near all the work now, I have a reasonably good set of processes and controls, and this was a gap. It's working through merging and responding now.

Currently I have a private repo with significantly more content such as test harness, tools, build scripts etc. I only push what is needed to release where I can as there is a lot of noise other wise - Including hiding the multitude of commits, so I was getting it to 'batch up' for release. I've got it to recreate the sub-commits going forward.

Thanks for your submission, it's appreciated.

Thanks

John