#GOG skill works via CLI but OpenClaw agent says no Gmail bridge available

1 messages · Page 1 of 1 (latest)

fallen idolBOT
#

The gog skill doesn’t add a “Gmail bridge” by itself — it just teaches the model: “when you need Gmail, run the gog 
 CLI”. For that to actually work in chat, two things must be true at runtime:

  1. the skill is eligible/loaded (OpenClaw can see gog on PATH)
  2. the agent is allowed to use a command execution tool (exec / group:runtime) in that session (and, if sandboxed, it can run gog inside the sandbox or run elevated on host)

When either of those fails, the model will do exactly what you’re seeing: draft + confirmation, then “can’t actually send”.

Quick verification (run on the VPS as the same user that runs the gateway service)

openclaw skills info gog
openclaw skills list --eligible | rg -i gog
openclaw skills check
openclaw sandbox explain

What to look for:

#
  • openclaw skills check should not report gog as missing from PATH.
    If it does: your gateway service environment likely can’t see where gog is installed (common with systemd + Linuxbrew).
  • openclaw sandbox explain will tell you if the Web UI chat session is sandboxed (often agents.defaults.sandbox.mode: "non-main" surprises people) and whether exec is blocked by tool policy inside the sandbox.

Docs:

The 3 most common fixes

A) gog isn’t on PATH for the gateway service

  • If you installed via Linuxbrew, make sure the service PATH includes the brew bin dir (or symlink gog into something like ~/.local/bin that systemd already sees).
  • After fixing PATH: openclaw gateway restart, then start a fresh chat (/new) so the skills snapshot refreshes.

B) Tool policy blocks exec
If you set a restrictive tools.profile / tools.allow, you must allow runtime tools:

#
  • allow exec (or group:runtime) in tool policy

(If you paste your tools section from ~/.openclaw/openclaw.json, I can tell you the minimal safe allowlist for “send Gmail via gog”.)

Tool policy docs: https://docs.openclaw.ai/tools (see tool profiles + group:runtime)

C) The session is sandboxed
If the Web UI session is sandboxed, exec runs in Docker by default, and then:

  • gog may not exist inside the container
  • the container won’t automatically have your ~/.config/gogcli tokens

Simplest fix: disable sandbox for the agent that’s supposed to send email, or configure the sandbox to install gog + mount/provide the gog config.

About env vars (GOG_ACCOUNT)

Not strictly required, but recommended if you have multiple accounts. You can set GOG_ACCOUNT=you@gmail.com so the agent doesn’t need --account .... (Just keep in mind OpenClaw env loading never overrides existing values.)
Docs: https://docs.openclaw.ai/help/environment

#

If you paste the output of openclaw skills check + openclaw sandbox explain (and your tools: config block), I can point to the exact line that’s preventing the agent from using gog.

#

Nice — your pasted outputs basically prove this is not a “gog skill install” problem:

  • 📩 gog ✓ Ready (skill is eligible and loaded)
  • Effective sandbox 
 runtime: direct 
 mode: off (so you’re not in Docker; exec should run on-host)

So the remaining usual culprit is: exec is being blocked by exec-approvals policy, and the model is “papering over” the deny as “no bridge available”.

1) Check exec approvals + tools.exec policy (most important)

Run these on the VPS:

openclaw config get tools.exec
openclaw approvals get --gateway

In the approvals get output, look at:

#
  • defaults.security (deny vs allowlist vs full)
  • defaults.ask / defaults.askFallback
  • whether there’s an allowlist entry that would match the resolved path of gog

If security: deny, then no host exec will ever run (even though the exec tool exists).

Docs: https://docs.openclaw.ai/tools/exec-approvals and https://docs.openclaw.ai/cli/approvals

2) Quick fix: allowlist the gog binary for the gateway host

First get the absolute path:

command -v gog

Then allowlist it (exact path is fine):

# 
openclaw approvals allowlist add --gateway --agent main "$(command -v gog)"

Now retry in Web UI.

If your approvals security is currently deny, you’ll need to flip it to allowlist (or full) in the gateway approvals file (you can do that by editing ~/.openclaw/exec-approvals.json or by openclaw approvals set --gateway --file 
).

3) Confirm whether the model is even attempting an exec

When you reproduce from Web UI, tail logs:

openclaw logs --follow

You’re looking for anything like exec.approval.requested, exec.denied, EXEC_*, etc. If you see denials, it’s 100% approvals/policy, not skills.

#

If you paste just these bits (redact any socket token if shown):

  • openclaw config get tools.exec
  • the defaults section from openclaw approvals get --gateway


I can tell you the exact minimal change to make gog gmail send work while keeping your exec safety guardrails.

#

That output is super telling:

  • Approvals 
 No allowlist entries. → your gateway host currently has zero approved binaries for exec approvals.
  • The Web UI chat “dry-run → confirm → ‘no gmail bridge’” pattern is exactly what happens when the model could use exec, but host exec is effectively blocked by approvals / security so it never successfully runs gog.

Two things to do next:

1) Re-run approvals in a pasteable format (so we can see defaults)

Your earlier approvals get table got eaten by the logger. Use JSON mode:

openclaw approvals get --gateway --json

Redact socket.token if it appears, then paste the rest. We mainly need to see:

  • file.defaults.security
  • file.defaults.ask
#
  • file.defaults.askFallback
  • file.defaults.autoAllowSkills

(Those determine whether exec is deny, allowlist, or full, and whether a missing UI prompt falls back to deny.)

2) Quick fix: allowlist the gog binary for the gateway host

This is the most common “make gog skills actually run” fix:

openclaw approvals allowlist add --gateway --agent main "$(command -v gog)"

Then start a fresh Web UI session (/new) and try something very explicit, e.g.:

“Use the gog skill. Run gog gmail send --to 
 --subject 
 --body 
.”

If it still refuses, the next check is your tools.exec config (because effective policy is the stricter of tools.exec.* and approvals defaults):

# 
openclaw config get tools.exec

Paste that too.

Side note: the warning
tools.profile (coding) allowlist contains unknown entries (apply_patch, image)
is usually harmless (those tools are only “loaded” when configured), and it’s not related to Gmail sending.

If the allowlist add fixes it, please mark the solution in the thread so Answer Overflow indexes it.

#

You’re basically there now — that last paste contains the missing puzzle piece.

What’s happening

  • You did add the gog binary to exec-approvals.json ✅
  • But your agent is still unable to actually run it because exec defaults to host=sandbox, and your sandbox explain shows mode: off.

In current OpenClaw behavior, “sandbox host while sandboxing is off” fails closed, so the model can’t run commands and starts flailing (in your case: trying sessions_spawn with runtime=acp, which then errors because you don’t have the ACP backend plugin configured).

This is exactly the line from the exec docs:

Fastest test (no config change): set per-session exec host in Web UI

#

In Web UI chat, send this as a standalone message:

/exec host=gateway security=allowlist ask=on-miss

Then try again: “Send an email 
” (with explicit to, subject, body).

If that works, make it permanent in config:

Permanent fix (config)

Run on the VPS:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security allowlist
# 
openclaw config set tools.exec.ask on-miss

Since your gog is in Linuxbrew, also make sure exec can find it by name (PATH prepend):

openclaw config set tools.exec.pathPrepend '["/home/linuxbrew/.linuxbrew/bin"]' --strict-json

Then restart:

openclaw gateway restart

Your approvals file already has:

#

/home/linuxbrew/.linuxbrew/bin/gog ✅

So gog 
 should now run without prompting (because it matches allowlist and ask=on-miss).

About the ACP error

You don’t need ACP for this at all — that was just the model picking the wrong tool because exec couldn’t run. Once exec host=gateway works, that error should disappear.

(If it still keeps trying ACP, we can also just tools.deny: ["sessions_spawn"], but I’d only do that after confirming exec works.)

If you confirm /exec host=gateway 
 fixes it, please mark the solution so it gets indexed.

#

Perfect — those config changes are exactly what was needed.

What you’re hitting now is purely process management:

Why openclaw gateway restart failed

openclaw gateway restart only restarts a supervised service (systemd user unit / launchd / scheduled task). Your output says the gateway service isn’t installed/enabled, so there’s nothing for the CLI to restart.

So the config is updated, but your currently running gateway process (if any) hasn’t been restarted yet.

Option A (fastest): restart the foreground gateway process you’re already running

If you started it with something like:

openclaw gateway --tailscale serve
#

Just stop that process (Ctrl‑C in the tmux/screen/SSH session where it’s running), then start it again with the same command. That will pick up the new tools.exec.* settings.

If you don’t remember where it’s running:

ps aux | grep '[o]penclaw gateway'

Then kill <pid> and re-run openclaw gateway --tailscale serve.

Option B (recommended long-term): install the systemd service so restart works

Try:

# 
openclaw gateway install

If you still get “systemd user services are unavailable”, you’re usually in one of two cases:

  • Container / no systemd → you can’t use user services; stick to tmux/supervisor.
  • Real Ubuntu VPS, but user services not kept alive → enable lingering:
sudo loginctl enable-linger openclaw
openclaw gateway install --force
systemctl --user start openclaw-gateway.service

(That’s the standard fix on headless boxes.)

#

Docs: https://docs.openclaw.ai/cli/gateway and https://docs.openclaw.ai/platforms/linux

After restart, quick smoke test in Web UI

Start a fresh session (/new) and ask something explicit like:

“Use the gog skill. Send an email to X with subject Y and body Z.”

Now that tools.exec.host=gateway + security=allowlist and gog is allowlisted, it should actually execute instead of trying ACP.

If it works now, please mark the solution in the thread so it’s indexed.

#

Nice — that’s the “good” failure now: OpenClaw is running gog, and gog is rejecting the send because it doesn’t know which account to use.

That happens when you have multiple gog auth entries (or no default set). Fix is either: set a default account in gog, or set GOG_ACCOUNT, or pass --account each time.

Quickest fix (no restart): retry with --account

First list the accounts gog knows:

gog auth list

Then in Web UI ask it to retry with e.g.:

gog gmail send --account "myemail@gmail.com" --to ... --subject ... --body ...
#

Durable fix (recommended): set GOG_ACCOUNT for OpenClaw

Pick one of these:

A) Global env for the gateway (simple)

openclaw config set env.vars.GOG_ACCOUNT "myemail@gmail.com"

Then restart your running gateway process (same way you restarted it earlier), so the new env is definitely picked up.

B) Skill-scoped env (cleaner)

openclaw config set skills.entries.gog.env '{"GOG_ACCOUNT":"myemail@gmail.com"}' --strict-json

(Again: restart the gateway process to be safe.)

#

Alternative: set default inside gog

Run:

gog auth manage


then set the default account there (so gog gmail send ... works without --account anywhere).

Once GOG_ACCOUNT (or a default account) is set, the “no Gmail bridge” issue should be fully gone — it’ll just work via exec + gog. If this fixes it, please mark the solution in the thread so it’s indexed.

#

That prompt is coming from gog, not OpenClaw: your gog keyring backend is file, and exec runs are non‑interactive, so gog can’t stop and ask you to type the passphrase.

What to do (recommended)

Set the passphrase in an env var so gog can unlock non-interactively:

  • GOG_KEYRING_PASSWORD = the passphrase for ~/.config/gogcli/keyring
  • (and you probably also want) GOG_ACCOUNT=you@gmail.com so it stops asking for --account

Best place for this on a gateway is ~/.openclaw/.env (so you don’t hardcode secrets into openclaw.json):

chmod 700 ~/.openclaw
touch ~/.openclaw/.env
chmod 600 ~/.openclaw/.env

# then edit ~/.openclaw/.env and add (DON'T paste it here):
# 
# GOG_KEYRING_PASSWORD=...
# GOG_ACCOUNT=you@gmail.com

Then restart your running gateway process (the openclaw gateway 
 process) so it picks up the env.

This is straight from gogcli docs: “Non-interactive runs (CI/ssh): file backend requires GOG_KEYRING_PASSWORD.”

“Change the passphrase?”

gogcli doesn’t have a nice “change passphrase” command in the normal flow. Practically, you either:

  • keep the passphrase and provide it via GOG_KEYRING_PASSWORD (simplest), or
  • recreate the keyring (which means re-auth / re-store tokens) if you truly want a different passphrase.

If you want, paste the output of gog auth keyring (it’s not secret) and gog auth list (redact emails if you want) and I’ll tell you the cleanest setup for your exact backend.

#

That error is coming straight from gog’s encrypted file keyring:

  • Enter passphrase to unlock ".../gogcli/keyring" → gog is using the file backend (auto-selected).
  • aes.KeyUnwrap(): integrity check failed → the passphrase you entered does not match what that keyring was encrypted with (or the keyring file is corrupted, but 99% of the time it’s just the wrong password).

1) First: try again with the exact original keyring password (non-interactive)

If you know the password, don’t rely on the interactive prompt (this is the same problem OpenClaw hits). Use the env var:

export GOG_KEYRING_PASSWORD='(your existing keyring password)'
gog --no-input auth list

(Obviously: don’t paste the password here.)

If that works, you’re done — put the same GOG_KEYRING_PASSWORD into ~/.openclaw/.env (plus GOG_ACCOUNT=...) and restart the gateway process.

#

2) If you don’t know the old password (or it still fails)

Then gog can’t decrypt the stored refresh tokens. There’s no magic recovery — you have to recreate the keyring + re-auth.

Do it safely (no data loss surprises) by backing up first:

mv ~/.config/gogcli/keyring ~/.config/gogcli/keyring.bak.$(date +%s)

Then force file backend + set a new password + re-add the account:

gog auth keyring file
export GOG_KEYRING_PASSWORD='(new password)'
gog auth add you@gmail.com --services gmail --manual
#

After that:

export GOG_KEYRING_PASSWORD='(new password)'
gog --no-input auth list

3) Once gog --no-input auth list works, OpenClaw will work

Because OpenClaw exec runs are non-interactive, the key is: gog must be usable with --no-input + env vars.

Recommended env vars for OpenClaw:

  • GOG_KEYRING_PASSWORD=...
  • GOG_ACCOUNT=you@gmail.com

If you tell me whether you remember the original keyring password (yes/no), I’ll suggest the least-painful path (unlock vs rebuild).

#

That’s the exact expected error for gog on a headless/non-interactive exec run:

no TTY available for keyring file backend password prompt; set GOG_KEYRING_PASSWORD

So the remaining step is simply: make gog’s keyring unlock non-interactively by providing the keyring password via env var in the gateway process environment.

1) Verify you know the correct keyring password (in a shell)

On the VPS, run (don’t paste the password anywhere):

export GOG_KEYRING_PASSWORD='your-keyring-passphrase'
gog --no-input auth list
  • If this works → you’re good.
  • If you still see “integrity check failed” → that password is wrong (or the keyring is corrupted) and you’ll need to rebuild the keyring + re-auth.
#

2) Provide it to OpenClaw (recommended: ~/.openclaw/.env)

Edit ~/.openclaw/.env (chmod 600 like you already did) and add:

  • GOG_KEYRING_PASSWORD=...
  • GOG_ACCOUNT=your@gmail.com (optional but recommended so it stops needing --account)

Then restart the running gateway process (since you’re not using the service, stop/start the openclaw gateway --tailscale serve process).

After restart, retry the Web UI send — it should no longer complain about TTY.

Docs reference (gogcli README): file backend + non-interactive requires GOG_KEYRING_PASSWORD.

Small extra: your Web UI command lost a space

It ran:
--to xx@outlook.com--subject 


Make sure there’s a space before --subject when you test again.

#

If you want the most “agent-friendly” end state, the winning combo is:
tools.exec.host=gateway + exec approvals allowlisted gog + .openclaw/.env containing GOG_KEYRING_PASSWORD + GOG_ACCOUNT.

When this works, please mark the solution in the thread so it’s indexed.

#

Those commands only create the file + set permissions — they don’t put any contents into it.

You need to edit ~/.openclaw/.env and add lines like:

  • GOG_KEYRING_PASSWORD=...
  • GOG_ACCOUNT=you@gmail.com

Option A (simplest): use nano

nano ~/.openclaw/.env

Then add (example):

GOG_KEYRING_PASSWORD=your-passphrase-here
# 
GOG_ACCOUNT=you@gmail.com

Save + exit:

  • Ctrl+O (write out) → Enter
  • Ctrl+X (exit)

If nano isn’t installed:

sudo apt update
sudo apt install -y nano

Option B (safer, avoids the password in shell history): prompt + write

This keeps the password out of your command history:

# 
read -s -p "GOG keyring password: " pw
echo
printf 'GOG_KEYRING_PASSWORD=%s\n' "$pw" >> ~/.openclaw/.env
unset pw

printf 'GOG_ACCOUNT=%s\n' "you@gmail.com" >> ~/.openclaw/.env
chmod 600 ~/.openclaw/.env

Verify it (don’t paste it here if it contains the password)

ls -la ~/.openclaw/.env

Then restart the gateway process

Stop/start your running openclaw gateway --tailscale serve process so it reloads ~/.openclaw/.env.

#

Important: don’t post the contents of .env in Discord — it’s a secret.

#

If you’re seeing the assistant flat-out claim “I don’t have a Gmail-sending tool available” (with no Exec tool call trace at all), that’s almost never a gog problem anymore — it means the model/session you’re currently on isn’t actually using tools (or it’s ignoring them).

You already proved tools work earlier (you got an actual Exec run + gog error output), so something changed in the current Web UI session.

Quick checks in the Web UI (fast, no SSH)

  1. Send as a standalone message:
/model status

Paste the output (it won’t include secrets).
If it shows something like an “auto” / weaker model choice, that’s a common reason tools get ignored.

  1. Send:
/exec

If tools are enabled in this session, it should print the current exec defaults. If it doesn’t / the assistant still roleplays, tools aren’t being exposed/used for that run.