Hi @resin1980 @Joly0 I have almost finished a new version that should address both of these.

@Joly0 To be sure, if your system still has the debug log, it would be helpful so I can double check not an unrelated issue to what I have fixed.

Thanks

John

Antigravity Cli added, along with a number of fixes and a few other enhancements.

On 5/23/2026 at 9:25 AM, johner said:

Antigravity Cli added, along with a number of fixes and a few other enhancements.

Hi John,

You are doing an amazing job with this plugin, really appreciate your hard work on it!

I ran into an issue when trying to install the Antigravity agent through the WebUI, which triggers this error: Fatal Error: Class "AICliAgents\Services\Sources\UrlValidator" not found

Why it's happening: The plugin is currently missing an autoloader definition for subdirectories under src/includes/services/. Because UrlValidator.php lives inside a nested sources/ subfolder (src/includes/services/sources/UrlValidator.php), its namespace AICliAgents\Services\Sources isn't being registered by the flat file inclusions in the manager.

The Fix: Adding a directory map fallback or explicitly globbing the subfolder inside src/includes/AICliAgentsManager.php right after InstallerService.php fixes the issue completely:

PHP

require_once __DIR__ . '/services/InstallerService.php';
// Load underlying source engines and validators
foreach (glob(__DIR__ . '/services/sources/*.php') as $file) { 
    require_once $file; 
}

Additionally, a PSR-4 compliant symlink structure or folder rename from src/includes/services/sources/ to match the capitalized namespace layout (src/Services/Sources/) resolves the autoloader mismatch permanently.

Thanks again for building this awesome tool!

Hi John,

Following up on the agent support, I also ran into two issues regarding the new Antigravity CLI ( agy ) command-line integration and credential persistence over SSH:

### 1. Missing SSH Integration & Shim for agy

• Why it's happening: The agy agent is currently omitted from the default shell integration files. There is no agy alias in the global profile, and no proxy shim generated in /usr/local/bin .

• The Fix:

• In src/scripts/installer/runtime.sh : Add the create_proxy call for the Go binary:

create_proxy "agy" "antigravity-cli/home/.local/bin/agy"

• In src/scripts/installer/shell-integration.sh : Add the persistent-home alias:

alias agy='_aicli_run /usr/local/emhttp/plugins/unraid-aicliagents/agents/antigravity-cli/home/.local/bin/agy'

──────

### 2. Keyring Persistence Failure (Credentials Not Saving to Disk)

• Why it's happening: The new agy agent uses the virtual DBus Secret Service keyring to encrypt and store OAuth tokens. However, the background daemon fails to write to disk, throwing this error in the daemon log:

save: write: open /tmp/unraid-aicliagents/work/root/home/.local/share/aicli-keyring/keyring.json.tmp: no such file or directory

Because the OverlayFS mount shadows underlying folders, the required storage directory ( .local/share/aicli-keyring/ ) does not exist on the active mount. The keyring daemon is forced to run entirely in-memory, clearing your authentication every time the daemon

or system restarts.

• The Fix:

Ensure the parent directories are created on the active mount in the secret-service-up.sh script (or during the home mount process) before the daemon launches:

mkdir -p "$HOME_DIR/.local/share/aicli-keyring"

Once these are merged, agy will be fully authenticated, persistent, and available out-of-the-box in all SSH terminal sessions!

Thanks again!

On 5/26/2026 at 3:10 AM, Sanjay said:

Hi John,

Following up on the agent support, I also ran into two issues regarding the new Antigravity CLI ( agy ) command-line integration and credential persistence over SSH:

### 1. Missing SSH Integration & Shim for agy

• Why it's happening: The agy agent is currently omitted from the default shell integration files. There is no agy alias in the global profile, and no proxy shim generated in /usr/local/bin .

• The Fix:

• In src/scripts/installer/runtime.sh : Add the create_proxy call for the Go binary:

create_proxy "agy" "antigravity-cli/home/.local/bin/agy"

• In src/scripts/installer/shell-integration.sh : Add the persistent-home alias:

alias agy='_aicli_run /usr/local/emhttp/plugins/unraid-aicliagents/agents/antigravity-cli/home/.local/bin/agy'

──────

### 2. Keyring Persistence Failure (Credentials Not Saving to Disk)

• Why it's happening: The new agy agent uses the virtual DBus Secret Service keyring to encrypt and store OAuth tokens. However, the background daemon fails to write to disk, throwing this error in the daemon log:

save: write: open /tmp/unraid-aicliagents/work/root/home/.local/share/aicli-keyring/keyring.json.tmp: no such file or directory

Because the OverlayFS mount shadows underlying folders, the required storage directory ( .local/share/aicli-keyring/ ) does not exist on the active mount. The keyring daemon is forced to run entirely in-memory, clearing your authentication every time the daemon

or system restarts.

• The Fix:

Ensure the parent directories are created on the active mount in the secret-service-up.sh script (or during the home mount process) before the daemon launches:

mkdir -p "$HOME_DIR/.local/share/aicli-keyring"

Once these are merged, agy will be fully authenticated, persistent, and available out-of-the-box in all SSH terminal sessions!

Thanks again!

Hey! These should be fixed now, thx for the continued feedback.

hi, great idea for a plugin. Is there a way to configure open code to use the local ollama ? in normal setup i can use ollama launch opencode as ollama has integration and inserts the integration (it emulates openai) but when i do it on unraid it says open code not installed

Hi!

So I assume the opencode agent works fine on its own?

How are you launching ollama etc.? In the standard unraid terminal, the little terminal button on the workspace drawer tab or another way?

Once I know I’ll see if I can get Claude to design a way to support this launch method.

In the interim use kilo (or opencode) free models to config the local models in opencode so you can launch it as blower the current design :-)

Edited June 13Jun 13 by johner

Hey, i have seen you recently added a global mcp server configuration. One thing though, i have seen http type mcp servers have basically no additional things to configure, but http (and i think this applies to sse servers aswell) can have authentication (mainly through headers), which currently wouldnt work with the way those are configured.
For example in my claude.json file i have an mcp server configured like this:

"mcpServers": {
    "Coding": {
      "type": "http",
      "url": "https://mymcp.mydomain.org/Coding/mcp",
      "headers": {
        "X-API-Key": "RANDOMAPIKEY"
      }
    }
  },

It would be great, if this was possible to configure (you could keep that simple and just allow headers in general to be configurable and the user has to handle which and how these headers are added, but thats up to you).

I tried the plugin and it wasn't for me. I removed the plugin via the Unraid plugin manager but my Unraid phplog is being now spammed with

[20-Jul-2026 03:19:47 UTC] PHP Fatal error:  Uncaught Error: Failed opening required '/usr/local/emhttp/plugins/unraid-aicliagents/src/includes/AI>
Stack trace:
#0 {main}

The log file has grown to 600+ MB in a few days.

6 hours ago, Jdiesel said:

I tried the plugin and it wasn't for me. I removed the plugin via the Unraid plugin manager but my Unraid phplog is being now spammed with

[20-Jul-2026 03:19:47 UTC] PHP Fatal error:  Uncaught Error: Failed opening required '/usr/local/emhttp/plugins/unraid-aicliagents/src/includes/AI>
Stack trace:
#0 {main}

The log file has grown to 600+ MB in a few days.

oh wow! ok, sorry about that, let me check and fix.

Have you been able to remove what ever is left behind manually? If not, point a local instance of one of your coding agents at the server via ssh, it'll figure it out and remove it.

Out of interest, and feedback on what would have made it useful for you?

Thanks

John

34 minutes ago, johner said:

oh wow! ok, sorry about that, let me check and fix.

Have you been able to remove what ever is left behind manually? If not, point a local instance of one of your coding agents at the server via ssh, it'll figure it out and remove it.

Out of interest, and feedback on what would have made it useful for you?

Thanks

John

I did manually delete the plugin folder with where the config files lived as suggested by the uninstall script. I think I enabled one server when I tried the app and didn't stop or uninstall the server before uninstalling the plugin. I'm not a big fan on pointing an agent at my production server, even if it is in read-only mode.

I decided to just run a local instance of OpenCode CLI because it supported all my providers and allowed me to fine-tune my build environment better.