Not able to run google workspace automatically | Friends of the Crustacean 🦞🤝 | Page 1

dire kite Mar 12, 2026, 6:31 AM

#

I have just install Google workspace cli I want to automate it but my openclaw can't do it as it can't run shell commands

lucid coralBOT Mar 12, 2026, 6:33 AM

#

OpenClaw can run shell commands — but only if:

the exec tool is allowed in your tool policy, and
the command exists on the machine where the Gateway (or a node) is running.

1) Check what error you get

When you try, do you see something like “tool exec not allowed / not found” or is it just silently refusing?
Also: what’s your version?

Please paste:

openclaw --version
openclaw status

2) Enable shell/command tools (`exec`)

In ~/.openclaw/openclaw.json (JSON5), allow the runtime tools:

#

Option A (simplest):

{
  tools: { profile: "coding" }
}

Option B (minimal change):

{
  tools: { allow: ["group:runtime"] } // enables exec/bash/process
}

If you’re running sessions in a sandbox, you may also need to allow runtime tools in the sandbox policy:

#

{
  tools: {
    sandbox: {
      tools: { allow: ["group:runtime"] }
    }
  }
}

Docs: https://docs.openclaw.ai/tools

3) Make sure the CLI is installed on the right machine

If your Gateway runs on a VPS, but you installed the Google Workspace CLI on your laptop, OpenClaw won’t see it.

You have 2 choices:

Install the CLI on the Gateway host (same machine running OpenClaw Gateway), or

#

Pair your laptop as a node and run commands on that node (best when the CLI is only on your laptop).

Relevant docs:

Nodes (run things on your own device): https://docs.openclaw.ai/nodes
Exec approvals/allowlisting (so it’s not “run anything”): https://docs.openclaw.ai/tools/exec-approvals

If you paste the exact error message you get when it tries to run a command, I can point to the specific fix (tool policy vs sandbox vs missing binary).

dire kite Mar 12, 2026, 6:35 AM

#

"tools": {
"profile": "full",
"allow" : ["*"],
"deny" : [],
"exec": {
"host": "gateway",
"ask" : "off"
}
},

this is my config why it is not working

#

I want to use it via telegram

#

As well

lucid coralBOT Mar 12, 2026, 6:37 AM

#

That config does enable the exec tool, but there’s a second gate you’re hitting:

Tool allowlist ≠ “allowed to run any command”

tools.allow: ["*"] only means the model is allowed to call the exec tool.
Whether a command actually runs on host=gateway is controlled by Exec Approvals (and tools.exec.security / ask).

With this combo:

tools: {
  exec: {
    host: "gateway",
    ask: "off"
  }
}

#

…you’ve basically said: “run on the gateway host, and never prompt me”.

But if your effective exec security is allowlist (common default for gateway/node), then anything not already allowlisted gets denied — and since ask is off, you never get a prompt to approve it.

What to do (pick one)

Option A (recommended): keep allowlist, turn prompts back on

Set:

{
  tools: {
    exec: {
      host: "gateway",
      ask: "on-miss"
    }
  }

#

Then allowlist the actual binary you want to run (on the gateway host):

See current approvals:

openclaw approvals get --gateway

Add your CLI binary path to allowlist (example):

openclaw approvals allowlist add --gateway "/usr/local/bin/<your-cli>"

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

#

Approvals CLI: https://docs.openclaw.ai/cli/approvals

Option B (quick + unsafe): set full exec

If this is a private, trusted bot (no untrusted users/content), you can set:

{
  tools: {
    exec: {
      host: "gateway",
      security: "full",
      ask: "off"
    }
  }
}

Be careful: this is effectively “the AI can run anything on your machine”.

#

Also check: is the CLI installed on the gateway machine?

If your Gateway is on a VPS/Docker, but you installed the Google Workspace CLI on your laptop, the bot won’t find it.

If you paste:

the exact error message you see when it tries to run a command (or your openclaw logs --follow snippet), and
output of openclaw approvals get --gateway

…I can tell you which of the two issues it is (approval-deny vs command-not-found/PATH).

#

Telegram is just the “chat surface” — once Telegram is configured, you can DM your bot there and ask it to run the Google Workspace CLI the same way. The commands will run on the Gateway host (so the CLI must be installed on that machine / in that container).

1) Set up Telegram channel

Create a bot token via BotFather, then add this to ~/.openclaw/openclaw.json:

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing", // safest to start
      groups: { "*": { requireMention: true } },
    },
  },
}

#

Docs: https://docs.openclaw.ai/channels/telegram

2) Restart gateway + approve your DM

openclaw gateway restart
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Then DM the bot in Telegram again.

3) Important for your CLI automation

If OpenClaw is running on a VPS/Docker, you must install the Google Workspace CLI on that Gateway host (or adjust tools.exec.pathPrepend so the gateway can find it).
Don’t set Telegram to “open” unless you really want strangers DM’ing a bot that can run shell commands.

If you tell me where your Gateway is running (local machine vs VPS vs Docker) and the exact CLI command name you installed (e.g. gcloud … / gam … / gw …), I can tell you the cleanest way to make exec find it (PATH vs install location vs container).

#

Yes — you can run Discord + Telegram at the same time on one Gateway.

Just add Telegram config in addition to whatever you already have for Discord:

{
  channels: {
    discord: {
      // your existing discord config
    },
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing",
    },
  },

#

Then restart and check both are up:

openclaw gateway restart
openclaw channels status

After that you can DM the bot on Telegram and it will use the same tools/exec setup (still subject to exec approvals + the CLI being installed on the gateway host).

If your main goal is “run Google Workspace CLI from Telegram”, the next thing I need is:

where your Gateway is running (local / VPS / Docker), and
the exact error you get when it tries to run a simple command like uname -a or your workspace CLI command.

dire kite Mar 12, 2026, 8:20 AM

#

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'{

"error": {
"code": 500,
"message": "HTTP request failed: builder error: failed to parse header value",
"reason": "internalError"
}}
o
penclaw@DESKTOP-3NP8G6B:~$

I am getting this error now

lucid coralBOT Mar 12, 2026, 8:23 AM

#

That error is coming from gws itself (not OpenClaw). OpenClaw/exec is working now — it’s just running a command that fails.

builder error: failed to parse header value almost always means one of the HTTP header values contains an invalid character (most commonly a hidden \r / newline in an auth token).

1) First: fix the command (you have an extra `{`)

Run it exactly like this (no trailing {):

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

2) Check if you have a bad token env var set (common on Windows/WSL)

Run:

env | grep GOOGLE_WORKSPACE_CLI

#

If you see GOOGLE_WORKSPACE_CLI_TOKEN=..., that token is used at highest priority and it’s the most likely place a hidden \r snuck in.

Try unsetting it and retry:

unset GOOGLE_WORKSPACE_CLI_TOKEN
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

3) Re-auth the “normal” way (recommended for automation)

If you haven’t yet:

gws auth setup
# or
gws auth login

#

Auth docs (shows env var precedence too): https://googleworkspace-cli.mintlify.app/concepts/authentication

4) If you do need `GOOGLE_WORKSPACE_CLI_TOKEN`, strip Windows CR

If you’re setting it from something like gcloud auth print-access-token, do:

export GOOGLE_WORKSPACE_CLI_TOKEN="$(gcloud auth print-access-token | tr -d '\r')"

Then retry the gws sheets spreadsheets create ... command.

If you paste the output of env | grep GOOGLE_WORKSPACE_CLI (redact token values) + gws --version, I can tell you which auth path you’re on and what to change for a headless/OpenClaw + Telegram setup.

dire kite Mar 12, 2026, 8:25 AM

#

I did number 3

lucid coralBOT Mar 12, 2026, 8:26 AM

#

Good — gws auth setup/login done means you shouldn’t need GOOGLE_WORKSPACE_CLI_TOKEN anymore.

If you’re still getting failed to parse header value, the usual cause is:

you still have GOOGLE_WORKSPACE_CLI_TOKEN set somewhere (often via a .env file), and it contains a hidden \r / newline — so the Authorization header becomes invalid.

Do these 3 quick checks

Make sure your command is clean (no extra { at the end):

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

See if a token/env var is overriding your new login

env | grep GOOGLE_WORKSPACE_CLI

#

If you see GOOGLE_WORKSPACE_CLI_TOKEN=..., remove it:

unset GOOGLE_WORKSPACE_CLI_TOKEN

Check if you have a .env file (gws auto-loads it)
From the same folder you run gws in:

ls -la .env

If .env exists and contains GOOGLE_WORKSPACE_CLI_TOKEN=..., that will keep overriding auth even after login. Also check for Windows CRLF (^M):

sed -n 'l' .env | head

As a super fast test to prove it’s a local .env issue:

#

cd /tmp
gws drive files list --params '{"pageSize": 1}'

Post back the output of (2) (redact values) and whether the /tmp test works, and we’ll nail the exact fix.

dire kite Mar 12, 2026, 9:32 AM

#

rm /home/openclaw/.config/gws/credentials.enc
openclaw@DESKTOP-3~/.openclaw$ echo "openclaw-static-key-12345" > /home/openclaw/.config/gws/.encryption_key
openclaw@DESKTOP-3NB:~/.openclaw$ gws auth login
Open this URL in your browser to authenticate:

https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/gmail.modify https://www.googleapis.com/auth/documents https://www.googleapis.com/auth/presentations https://www.googleapis.com/auth/spreadsheets https://www.googleapis.com/auth/tasks https://www.googleapis.com/auth/cloud-platform openid https://www.googleapis.com/auth/userinfo.email&access_type=offline&redirect_uri=http://localhost:43209&response_type=code&client_id=856231542949-buh4ih3hki6814f20l0b18pgsoksb08a.apps.googleusercontent.com&prompt=select_account+consent

lucid coralBOT Mar 12, 2026, 9:32 AM

#

Nice — that output means gws auth login worked and it successfully wrote encrypted creds to:

/home/openclaw/.config/gws/credentials.enc
using /home/openclaw/.config/gws/.encryption_key (since you’re headless)

Next: test the exact Sheets call again

Run:

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

If that works in your shell, OpenClaw can run the same command via exec (Telegram is just the chat transport).

Two important notes (so it keeps working under OpenClaw service)

Permissions on the key file
Make sure it’s not world-readable:

#

chmod 600 /home/openclaw/.config/gws/.encryption_key
chmod 600 /home/openclaw/.config/gws/credentials.enc

Don’t use a static key long-term
openclaw-static-key-12345 is predictable. Better:

openssl rand -hex 32 > /home/openclaw/.config/gws/.encryption_key
chmod 600 /home/openclaw/.config/gws/.encryption_key

(You’d need to re-login after changing the key, since it can’t decrypt old creds.)

If the `gws ... create` command now works, but OpenClaw still can’t run it

Then it’s almost certainly exec approvals/allowlist on the gateway host. We’ll fix that by allowlisting the gws binary path.

#

Post the output of:

which gws
openclaw approvals get --gateway

(redact anything sensitive), and I’ll give you the exact allowlist add command.

dire kite Mar 12, 2026, 9:37 AM

#

chmod 600 /home/openclaw/.config/gws/.encryption_key
openclaw@DESKTOP-3NP8G6B:~/.openclaw$ chmod 600 /home/openclaw/.config/gws/credentials.enc
openclaw@DESKTOP-3NP8G6B:~/.openclaw$ gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'
{
"error": {
"code": 500,
"message": "HTTP request failed: builder error: failed to parse header value",
"reason": "internalError"
}
}
openclaw@DESKTOP-3NP8G6B:~/.openclaw$

lucid coralBOT Mar 12, 2026, 9:38 AM

#

Auth is definitely OK now — but that same header-parse error after a successful login strongly suggests gws is still picking up a bad env var value (most commonly GOOGLE_WORKSPACE_CLI_TOKEN with a hidden \r), and that env var overrides your freshly saved encrypted credentials.

The big gotcha: you’re running this from ~/.openclaw, and gws auto-loads a .env file from the current directory. Many OpenClaw setups have ~/.openclaw/.env.

Quick isolation test (takes 10 seconds)

Run from a directory that definitely doesn’t have a .env:

cd /tmp
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

If it works from `/tmp`

Then your problem is your ~/.openclaw/.env (or ~/.openclaw environment) injecting something.

Check without pasting secrets:

#

cd ~/.openclaw
ls -la .env
rg -n "GOOGLE_WORKSPACE_CLI" .env || true
env | grep GOOGLE_WORKSPACE_CLI

If you find GOOGLE_WORKSPACE_CLI_TOKEN=... in that .env, remove that line (or fix CRLF). A Windows \r at end of the token line is exactly what triggers “failed to parse header value”.

Also run this (safe + helpful)

Dry run doesn’t touch auth and should always succeed:

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}' --dry-run

If --dry-run works but real run fails, it’s 100% an auth/header/env issue (not your JSON).

#

Reply with:

whether the /tmp run works, and
the output of rg -n "GOOGLE_WORKSPACE_CLI" ~/.openclaw/.env (just the lines/keys, redact values)

…and we’ll pinpoint the exact env var that’s breaking the header.

dire kite Mar 12, 2026, 9:40 AM

#

cd /tmp
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'
{
"error": {
"code": 500,
"message": "HTTP request failed: builder error: failed to parse header value",
"reason": "internalError"
}
}
openclaw@DESKTOP-3NP8G6B:/tmp$

lucid coralBOT Mar 12, 2026, 9:41 AM

#

Since it still fails in /tmp, it’s not your ~/.openclaw/.env file. At this point the two most common causes of builder error: failed to parse header value are:

a global GOOGLE_WORKSPACE_CLI_TOKEN env var (often with a hidden newline/\r), or
a proxy env var (HTTP_PROXY / HTTPS_PROXY / ALL_PROXY) with credentials/special characters that breaks the HTTP client builder.

1) Show the relevant env (redact values)

Run:

env | egrep -i 'GOOGLE_WORKSPACE_CLI|https?_proxy|all_proxy|no_proxy'

Don’t paste tokens/passwords — just show which vars are set.

2) Quick test: temporarily disable proxy + token env vars

In the same shell:

#

unset GOOGLE_WORKSPACE_CLI_TOKEN GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE GOOGLE_WORKSPACE_CLI_IMPERSONATED_USER
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy ALL_PROXY all_proxy NO_PROXY no_proxy

Then retry:

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

3) If it still fails, grab version + backtrace (to report upstream)

gws --version
RUST_BACKTRACE=1 gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

#

If you paste the output of step (1) (again, redact values), I can tell you immediately whether it’s the token override or a proxy setting causing the header parse failure.

dire kite Mar 12, 2026, 9:43 AM

#

env | egrep -i 'GOOGLE_WORKSPACE_CLI|https?_proxy|all_proxy|no_proxy'
GOOGLE_WORKSPACE_CLI_TOKEN={
openclaw@DESKTOP-3NP8G6B:/tmp$ unset GOOGLE_WORKSPACE_CLI_TOKEN GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE GOOGLE_WORKSPACE_CLI_IMPERSONATED_USER
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy ALL_PROXY all_proxy NO_PROXY no_proxy
openclaw@DESKTOP-3NP8G6B:/tmp$ gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'
{
"error": {
"code": 401,
"message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run gws auth logout and gws auth login to re-authenticate.",
"reason": "authError"
}
}

is it becasue i am running on wsl

lucid coralBOT Mar 12, 2026, 9:44 AM

#

Yep — WSL is very likely part of what you’re seeing, but there are actually two separate issues in your output:

1) Why you got the “failed to parse header value” (the 500)

This line is the smoking gun:

GOOGLE_WORKSPACE_CLI_TOKEN={

That env var has highest priority in gws, and the value { is not a valid bearer token, so the CLI tries to build an Authorization: Bearer { header and the HTTP client blows up with “failed to parse header value”.

Fix: remove that env var permanently

You already unset it in this one shell (good), but it’s being set somewhere like:

~/.bashrc / ~/.profile / ~/.zshrc
an .env file you source
OpenClaw’s service env (~/.openclaw/.env)

#

Search for it:

rg -n "GOOGLE_WORKSPACE_CLI_TOKEN" ~/.bashrc ~/.profile ~/.zshrc ~/.openclaw/.env 2>/dev/null

Delete that line (or correct it).

2) Why you now get “Failed to decrypt credentials” (401)

After unsetting the bad token, gws falls back to your encrypted credentials, but it can’t decrypt them:

“Credentials may have been created on a different machine…”

This happens a lot on WSL because the “OS keyring” story can be flaky there. You tried to force .encryption_key (good), but your current credentials.enc is still not decryptable with the key it’s using now.

Fix: logout + clean creds + login again (with the token env var NOT set)

Run:

#

unset GOOGLE_WORKSPACE_CLI_TOKEN
gws auth logout

rm -f ~/.config/gws/credentials.enc
rm -f ~/.config/gws/token_cache.json
rm -f ~/.config/gws/service_account_token_cache.json

gws auth login

Then re-test:

gws drive files list --params '{"pageSize": 1}'
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

#

If you want the most reliable automation for OpenClaw + Telegram

Don’t rely on interactive/keyring auth on WSL. Use headless credentials or a service account (so the Gateway can run it non-interactively).

But first, do the cleanup/login above and confirm gws drive files list ... works.

If you paste the rg ... GOOGLE_WORKSPACE_CLI_TOKEN ... result (just the matching line + file path), I can tell you exactly where that bad { is coming from.

dire kite Mar 12, 2026, 9:47 AM

#

gws drive files list --params '{"pageSize": 1}'
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'
{
"error": {
"code": 401,
"message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run gws auth logout and gws auth login to re-authenticate.",
"reason": "authError"
}
}
{
"error": {
"code": 401,
"message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run gws auth logout and gws auth login to re-authenticate.",
"reason": "authError"
}
}
openclaw@DESKTOP-3NP8G6B:/tmp$
still same

lucid coralBOT Mar 12, 2026, 9:49 AM

#

Yes — this is very consistent with WSL/keyring weirdness.

You found the root cause of the first error already:

GOOGLE_WORKSPACE_CLI_TOKEN={ was set → that caused “failed to parse header value”.
After you unset it, gws tries to use your encrypted creds → but WSL often can’t reliably persist the OS keyring encryption key, so decrypt fails on the next command.

The fix: force gws to use the `.encryption_key` file backend

gws only uses ~/.config/gws/.encryption_key when you set:

GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file

Do this in your shell first:

unset GOOGLE_WORKSPACE_CLI_TOKEN

#

export GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file

Then reset creds (since the old credentials.enc was encrypted with a different key backend) and log in again:

rm -f ~/.config/gws/credentials.enc
rm -f ~/.config/gws/token_cache.json ~/.config/gws/service_account_token_cache.json 2>/dev/null || true

# make sure the key file exists (use your existing one, or generate a fresh one)
openssl rand -hex 32 > ~/.config/gws/.encryption_key
chmod 600 ~/.config/gws/.encryption_key

gws auth login

#

Now test:

gws drive files list --params '{"pageSize": 1}'
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

Important: remove the bad token env var permanently

Otherwise it’ll come back every new shell / service start.

Search where it’s set:

rg -n "GOOGLE_WORKSPACE_CLI_TOKEN" ~/.bashrc ~/.profile ~/.zshrc ~/.openclaw/.env 2>/dev/null

Delete that line (or fix it).

#

If `GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND` doesn’t work

Then you’re on an older gws. Run:

gws --version

…and update to latest (npm i -g @googleworkspace/cli@latest).

Once this works in the terminal, we can wire the same env var into OpenClaw’s gateway service (so Telegram-triggered runs behave identically).

dire kite Mar 12, 2026, 9:50 AM

#

?

lucid coralBOT Mar 12, 2026, 9:51 AM

#

You’re hitting two different problems, so here’s the “do this exactly” version:

Goal

Make gws work reliably on WSL (so OpenClaw/Telegram can run it too).

Do this (copy/paste)

# 0) Make sure the broken token override is gone
unset GOOGLE_WORKSPACE_CLI_TOKEN

# 1) FORCE gws to use the file-based key (this is the WSL fix)
export GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file

# 2) Create a stable key file
mkdir -p ~/.config/gws
openssl rand -hex 32 > ~/.config/gws/.encryption_key

#

chmod 600 ~/.config/gws/.encryption_key

# 3) Remove the old encrypted creds (they were made with the wrong key backend)
rm -f ~/.config/gws/credentials.enc
rm -f ~/.config/gws/token_cache.json ~/.config/gws/service_account_token_cache.json 2>/dev/null || true

# 4) Login again
gws auth login

# 5) Test
gws drive files list --params '{"pageSize": 1}'

Then tell me what happens

Please paste:

#

gws --version

…and whether step (5) works.

If it works, the last step for OpenClaw is just: put
GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file
into ~/.openclaw/.env (and remove any GOOGLE_WORKSPACE_CLI_TOKEN=... line), restart the gateway, and you’re good for Telegram-triggered automation.

dire kite Mar 12, 2026, 10:04 AM

#

gws drive files list --params '{"pageSize": 1}'
{
"error": {
"code": 401,
"message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run gws auth logout and gws auth login to re-authenticate.",
"reason": "authError"
}
}
openclaw@DESKTOP-3NP8G6B:/tmp$ gws --version
gws 0.9.1
This is not an officially supported Google product.
openclaw@DESKTOP-3NP8G6B:/tmp$

lucid coralBOT Mar 12, 2026, 10:04 AM

#

gws 0.9.1 is new enough — so this should be fixable. What’s happening is: your credentials.enc was encrypted with a key that gws is not using consistently (classic on WSL when it flips between “keyring” vs “file”).

The easiest way to force it (even if your shell env isn’t sticking) is to prefix the command with the env var.

Do this exactly (forces file backend for this run)

# 0) make sure the bad override token is gone
unset GOOGLE_WORKSPACE_CLI_TOKEN

# 1) ensure the key file exists
mkdir -p ~/.config/gws
openssl rand -hex 32 > ~/.config/gws/.encryption_key
chmod 600 ~/.config/gws/.encryption_key

# 2) delete the encrypted creds (they’re currently undecryptable)
rm -f ~/.config/gws/credentials.enc

#

rm -f ~/.config/gws/token_cache.json ~/.config/gws/service_account_token_cache.json 2>/dev/null || true

# 3) re-login BUT force file backend
GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file gws auth login

Then test (also forced):

GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file gws drive files list --params '{"pageSize": 1}'

Quick sanity checks (tell me these outputs)

ls -la ~/.config/gws | sed -n '1,120p'

#

env | egrep -i 'GOOGLE_WORKSPACE_CLI_(TOKEN|KEYRING_BACKEND)'

Why this is WSL-related

WSL often doesn’t have a stable “OS keyring” service, so gws can end up generating/reading a different encryption key between runs. Forcing GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file makes the key come from ~/.config/gws/.encryption_key instead, which is stable and automation-friendly.

Once that works, we’ll set the same env var in the OpenClaw gateway service environment (so Telegram-triggered runs behave the same).

dire kite Mar 12, 2026, 10:08 AM

#

GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file gws drive files list --params '{"pageSize": 1}'
{
"error": {
"code": 401,
"message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run gws auth logout and gws auth login to re-authenticate.",
"reason": "authError"
}
}

are we stuck in a loop

lucid coralBOT Mar 12, 2026, 10:08 AM

#

Not a loop yet — you’re just still trying to use a credentials.enc that was encrypted with a different key/backend, so every API call will keep failing until you generate a fresh credentials.enc with the same backend you’re using to read it.

Right now you only ran the API call with GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file, but you haven’t shown a fresh auth login run with that same setting after deleting the old encrypted file.

Do this exactly

unset GOOGLE_WORKSPACE_CLI_TOKEN
export GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file

# delete the old encrypted creds (they are the thing that is undecryptable)
rm -f ~/.config/gws/credentials.enc

# now re-auth WITH the file backend enabled
gws auth login

# test (same shell)

#

gws drive files list --params '{"pageSize": 1}'

If that still fails, paste:

ls -la ~/.config/gws | sed -n '1,120p'
GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file gws auth status

Then we’ll know whether:

you’re writing creds to a different path than you’re reading from, or
gws 0.9.1 has a real bug on WSL and you should use the exported plaintext credentials file route (GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE) as the stable workaround for OpenClaw automation.

dire kite Mar 12, 2026, 10:10 AM

#

is it becasue i am login in in my browser not wsl?

lucid coralBOT Mar 12, 2026, 10:10 AM

#

No — the browser being “Windows” vs “inside WSL” is not the cause of this decrypt error.

How the flow works:

gws auth login (running in WSL) starts a tiny local web server on http://localhost:<port>
You open the URL in any browser (Windows is fine)
After you approve, Google redirects back to http://localhost:<port> and WSL receives the code
Then gws writes ~/.config/gws/credentials.enc

Your current error happens after that, when gws tries to decrypt credentials.enc locally and can’t. That’s purely about the encryption key/backend being inconsistent on WSL (keyring vs file), not about the browser.

What would cause this in practice

You logged in once with keyring backend, then later run commands with file backend (or vice versa), OR
The keyring backend on WSL is unstable, so the key changes between runs.

The fix (one more time, minimal)

Run everything in WSL:

#

unset GOOGLE_WORKSPACE_CLI_TOKEN
export GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file

rm -f ~/.config/gws/credentials.enc
# ensure key file exists and you DO NOT change it after this
test -f ~/.config/gws/.encryption_key || (openssl rand -hex 32 > ~/.config/gws/.encryption_key && chmod 600 ~/.config/gws/.encryption_key)

gws auth login
gws drive files list --params '{"pageSize": 1}'

If you want, paste just this (no secrets) so I can confirm you’re not accidentally switching environments:

ls -la ~/.config/gws

#

You’re not stuck in a loop — you’ve just hit the exact WSL failure mode:

gws auth login succeeds (it can encrypt and write credentials.enc)
but the next gws … run is a new process, and on WSL the “OS keyring” key it reads back is different / unavailable → so it can’t decrypt what it just wrote.

That’s why it fails immediately after a “success”.

The key point

You must force the file backend during the login that creates credentials.enc, not only during the API call.

Right now, you showed a successful login, but you didn’t show it was run with GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file, so it likely used the (broken) keyring backend.

Do this exactly (one clean run)

unset GOOGLE_WORKSPACE_CLI_TOKEN

#

# make sure the key file exists and stays constant
mkdir -p ~/.config/gws
test -f ~/.config/gws/.encryption_key || (openssl rand -hex 32 > ~/.config/gws/.encryption_key && chmod 600 ~/.config/gws/.encryption_key)

# delete the encrypted creds (they were created with the wrong backend)
rm -f ~/.config/gws/credentials.enc

# IMPORTANT: run auth login WITH the backend forced
GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file gws auth login

# test WITH the backend forced
GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file gws drive files list --params '{"pageSize": 1}'

If it still fails after that, I need 2 outputs

(no secrets inside)

#

env | egrep -i 'GOOGLE_WORKSPACE_CLI_(TOKEN|KEYRING_BACKEND)'
ls -la ~/.config/gws | sed -n '1,120p'

One more important thing: don’t regenerate .encryption_key again after login — changing it even once will make existing credentials.enc undecryptable.

dire kite Mar 12, 2026, 10:19 AM

#

GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file
total 24
drwx------ 3 openclaw openclaw 4096 Mar 12 10:15 .
drwxr-xr-x 5 openclaw openclaw 4096 Mar 12 08:38 ..
-rw------- 1 openclaw openclaw 65 Mar 12 10:05 .encryption_key
drwxr-xr-x 2 openclaw openclaw 4096 Mar 12 08:38 cache
-rw------- 1 openclaw openclaw 466 Mar 12 09:13 client_secret.json
-rw------- 1 openclaw openclaw 334 Mar 12 10:15 credentials.enc

lucid coralBOT Mar 12, 2026, 10:20 AM

#

Cool — this output is actually very helpful:

GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file is set
~/.config/gws/.encryption_key exists (65 bytes = 64 hex + newline)
credentials.enc exists

At this point there are only two realistic explanations for the decrypt failure:

credentials.enc was created before the file-backend/key was actually being used (so it’s encrypted with a different key), or
there’s a real bug in gws 0.9.1 on WSL around file-backend encryption/decryption.

Let’s distinguish those with one clean “fresh creds” run.

1) Create a brand new `credentials.enc` (don’t change `.encryption_key`)

Run exactly:

#

rm -f ~/.config/gws/credentials.enc
gws auth login

(Your env already shows GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file, so no need to prefix it.)

2) Immediately test decryption without calling Google APIs

This just checks “can I read/decrypt my creds”:

gws auth export --unmasked > /tmp/gws-creds.json
echo "export_ok"

Don’t paste /tmp/gws-creds.json (it contains secrets) — just tell me if you see export_ok or an error.

#

If `auth export` fails too

Then gws truly can’t decrypt on your WSL setup → that’s a gws bug/environment issue (and we should file an issue upstream).

If `auth export` works

Then decryption is fine, and the earlier “decrypt failed” message is misleading — we can switch to using the exported plaintext credentials file as a workaround:

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/tmp/gws-creds.json
gws drive files list --params '{"pageSize": 1}'

Reply with:

whether step (2) succeeds or fails, and the exact error text if it fails.

dire kite Mar 12, 2026, 10:23 AM

#

gws auth export --unmasked > /tmp/gws-creds.json
echo "export_ok"
export_ok

this is what i got

lucid coralBOT Mar 12, 2026, 10:23 AM

#

Perfect — that proves credentials.enc can be decrypted successfully on your machine. So the “Failed to decrypt credentials” error you see during API calls is either:

a gws bug/misreported error, or
something else in the API-call auth path (token cache, keyring backend mismatch, etc.)

Fastest workaround (and best for OpenClaw automation):

Use the exported plaintext credentials file via GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE.

Do this:

unset GOOGLE_WORKSPACE_CLI_TOKEN
export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/tmp/gws-creds.json

gws drive files list --params '{"pageSize": 1}'
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

#

If that works, make it persistent (don’t keep it in /tmp, it’ll disappear):

mkdir -p ~/.config/gws
mv /tmp/gws-creds.json ~/.config/gws/credentials.json
chmod 600 ~/.config/gws/credentials.json

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=~/.config/gws/credentials.json

Security note: that file contains your refresh token in plaintext. Treat it like a password (don’t share it, don’t commit it).

Then for OpenClaw + Telegram

Put this into OpenClaw’s daemon env file (on the gateway host):

~/.openclaw/.env

#

GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/home/openclaw/.config/gws/credentials.json
# DO NOT set GOOGLE_WORKSPACE_CLI_TOKEN

Restart the gateway, and your Telegram-triggered exec runs will inherit it.

Tell me what happens when you run the two gws … commands with GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE set.

dire kite Mar 12, 2026, 10:54 AM

#

WSL (specifically Google Workspace CLI/gws) often fails to decrypt credentials because newer versions (0.9.1+) struggle with persistent key storage in headless Linux environments, causing "Failed to decrypt credentials" errors. Downgrade to gws version 0.9.0, or ensure your environment supports a persistent keyring to fix this issue. [1]
Key Solutions for GWS/GPG on WSL:

Downgrade GWS: If you recently updated to 0.9.1, downgrade to 0.9.0, which handles key storage more reliably in WSL.
Setup Pinentry: If using GPG, install and configure pinentry-curses to handle passphrase prompts, as shown in this GitHub issue.
Add pinentry-program /usr/bin/pinentry-curses to ~/.gnupg/gpg-agent.conf.
- Add export GPG_TTY=$(tty) to your ~/.bashrc.
- Run gpg-connect-agent reloadagent.
Alternative Keys: If keys are missing, download them directly using curl and apt-key add rather than relying on automated key server lookups, as suggested in this Medium article. [1, 2, 3]

If this is a broader GPG issue, ensure your gpg-agent is running properly within the WSL session. Are you receiving a specific "failed to decrypt" error, or is it a GPG passphrase prompt failure? [1, 4]

[1] https://github.com
[2] https://github.com
[3] https://dsebastien.medium.com
[4] https://justyn.io

Look what I found

lucid coralBOT Mar 12, 2026, 10:55 AM

#

That’s a good find — and yes, issue #364 is basically your exact situation: gws 0.9.1 on Linux/WSL can think the keyring is “available”, write encrypted creds, and then later the key isn’t retrievable → credentials.enc becomes undecryptable.

A couple of notes about what you pasted:

The GPG / pinentry stuff is not relevant here. gws isn’t using GPG; it’s AES-256-GCM + (keyring or .encryption_key).
The “downgrade to 0.9.0” suggestion might help, but you already have a cleaner workaround.

Best workaround (you already proved it works): use plaintext credentials file

You successfully did:

gws auth export --unmasked > /tmp/gws-creds.json

Now use that file for API calls:

unset GOOGLE_WORKSPACE_CLI_TOKEN

#

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/tmp/gws-creds.json
gws drive files list --params '{"pageSize": 1}'
gws sheets spreadsheets create --json '{"properties":{"title":"Demon Test Sheet"}}'

If that works, make it persistent (don’t keep it in /tmp):

mkdir -p ~/.config/gws
mv /tmp/gws-creds.json ~/.config/gws/credentials.json
chmod 600 ~/.config/gws/credentials.json

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=~/.config/gws/credentials.json

Then wire it into OpenClaw (Telegram automation)

#

Put this in ~/.openclaw/.env on the gateway host:

GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/home/openclaw/.config/gws/credentials.json
# (and make sure GOOGLE_WORKSPACE_CLI_TOKEN is NOT set anywhere)

Restart the gateway and your Telegram-triggered exec runs will inherit it.

If you run the two gws … commands with GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE set, what do you get?

dire kite Mar 12, 2026, 11:02 AM

#

same error lets move back to old version

lucid coralBOT Mar 12, 2026, 11:03 AM

#

Got it — if you want to go back to an older gws, do it, but make sure you wipe + re-auth after the downgrade (because the encrypted store/key handling changed).

0) First, remove the broken env override (important)

Earlier you had GOOGLE_WORKSPACE_CLI_TOKEN={ which will break any version.

In your current shell:

unset GOOGLE_WORKSPACE_CLI_TOKEN

And also remove it wherever it was set (often ~/.openclaw/.env, ~/.bashrc, etc.).

1) Downgrade `gws` to 0.9.0

If you installed via npm:

#

npm i -g @googleworkspace/cli@0.9.0
gws --version

(That should overwrite 0.9.1.)

2) Reset gws auth files + re-login

rm -f ~/.config/gws/credentials.enc
rm -f ~/.config/gws/token_cache.json ~/.config/gws/service_account_token_cache.json 2>/dev/null || true

gws auth login

3) Test

#

gws drive files list --params '{"pageSize": 1}'

If you paste the output of gws --version after downgrade + the first failing command output, I’ll tell you what the next lever is (and how to make it work cleanly under OpenClaw/Telegram).

dire kite Mar 12, 2026, 11:06 AM

#

/tmp$ gws drive files list --params '{"pageSize": 1}'
{
"error": {
"code": 401,
"message": "Authentication failed: Failed to parse authorized user credentials from /tmp/gws-creds.json: missing field client_id",
"reason": "authError"
}
}
openclaw@DESKTOP-3NP8G6B:/tmp$

lucid coralBOT Mar 12, 2026, 11:07 AM

#

That new error is different (and good news): it means gws is now reading GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/tmp/gws-creds.json, but that JSON file is not in the expected “authorized_user” format.

gws expects the file to look like:

{
  "type": "authorized_user",
  "client_id": "...",
  "client_secret": "...",
  "refresh_token": "..."
}

Your /tmp/gws-creds.json clearly doesn’t contain client_id, so it’s either:

the wrong file (e.g. you pointed it at client_secret.json-style JSON), or
the export output isn’t what we think (or got overwritten).

#

Check the JSON keys only (safe to paste)

Run:

node -e "const j=require('/tmp/gws-creds.json'); console.log(Object.keys(j))"

Paste that output.

Regenerate the credentials file cleanly

In the same shell (and unset the credentials-file override while exporting):

unset GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE
gws auth export --unmasked > /tmp/gws-creds.json
node -e "const j=require('/tmp/gws-creds.json'); console.log(j.type, Object.keys(j))"

#

Then set it again and test:

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/tmp/gws-creds.json
gws drive files list --params '{"pageSize": 1}'

Also paste gws --version (after your downgrade) so we’re not mixing versions.

dire kite Mar 12, 2026, 11:08 AM

#

is it problem as i have isntall in tmp folder

node -e "const j=require('/tmp/gws-creds.json'); console.log(Object.keys(j))"
[ 'error' ]

lucid coralBOT Mar 12, 2026, 11:09 AM

#

Not because you “installed in /tmp” — gws is installed globally. The problem is that /tmp/gws-creds.json is not a credentials file anymore.

node showing:

[ 'error' ]

means /tmp/gws-creds.json currently contains something like:

{ "error": { ... } }

(i.e. it got overwritten by an error output), so of course gws can’t find client_id.

Fix: regenerate a real credentials.json (somewhere persistent)

#

First, stop gws from trying to read that broken file:

unset GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE
unset GOOGLE_WORKSPACE_CLI_TOKEN

Now export fresh creds to a non-/tmp path:

mkdir -p ~/.config/gws
gws auth export --unmasked > ~/.config/gws/credentials.json
chmod 600 ~/.config/gws/credentials.json

Verify it has the right keys (safe to paste the output):

#

node -e "const j=require(process.env.HOME+'/.config/gws/credentials.json'); console.log(Object.keys(j))"

You should see: type, client_id, client_secret, refresh_token.

Then use it:

export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=~/.config/gws/credentials.json
gws drive files list --params '{"pageSize": 1}'

If gws auth export --unmasked fails with the decrypt error, paste gws --version (after your downgrade) and the export error output — we’ll fix the encrypted-store side first, then export again.

dire kite Mar 12, 2026, 11:12 AM

#

gws drive files list --params '{"pageSize": 1}'
{
"files": [
{
"id": "17Rsr6txE7nHW0zX4LPkthlwmKc9XMwwft68QizPjZNI",
"kind": "drive#file",
"mimeType": "application/vnd.google-apps.spreadsheet",
"name": "Testlify Reddit Ops"
}
],
"incompleteSearch": false,
"kind": "drive#fileList",
"nextPageToken": "~!!~AI9FV7TFkre28Uw7IJbIUCPhYX28LM9ujCiv_naqlF-zKwiSwxdwi225pARyU-DYNpVoEM891RSOnawZQQdE3fFIaaZBgRurnejHI_FhccknXjeflnrcYyYC1Yr5vBhFM1QxLLrT4dfzX5s0CfGUZofgr4M-Mt_bO_qmkU4PikYIANBr6XZwzMsUsIQSuo8DqV_Op6RgXZxtwiuPkdc21EKLoxzX0P-ZR7wQ-GqKnwlGzKsg3InqYlgcCt5zoQFiz00z1ztuIm3cW4fgLrZQN6ap0xr3sPs2OtPFUnJhFwvqHmH-vOmMrlqoUC65pZlt9fE5JBlbufW-8BeeVngLPVyQu-j-sMofIw=="
}

lucid coralBOT Mar 12, 2026, 11:13 AM

#

Nice — that means gws is working correctly now.

What to do next so OpenClaw (Telegram) can run it too

Put the working creds file somewhere permanent (not /tmp) and lock permissions:

mkdir -p ~/.config/gws
# (use the file that worked for you)
chmod 600 ~/.config/gws/credentials.json

Make the OpenClaw Gateway service always have that env var
Add this to ~/.openclaw/.env on the machine running the Gateway:

GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/home/openclaw/.config/gws/credentials.json

#

Make sure you do NOT have GOOGLE_WORKSPACE_CLI_TOKEN set anywhere (that was the thing that originally broke requests).

Then restart OpenClaw:

openclaw gateway restart

From Telegram, once your Telegram channel is configured/pairing-approved, you can ask:

“Run gws drive files list --params '{\"pageSize\": 1}'”
“Create a sheet …”

If OpenClaw still refuses to run commands, that’s the separate exec approvals/allowlist layer — paste your current openclaw approvals get --gateway and I’ll tell you the exact allowlist entry to add for the gws binary.

If this fixed the original thread, please mark the solution (right-click the solution message → Apps → ✅ Mark Solution) so it’s indexed for others.

#

Good — gws + OpenClaw restart are working now. So we’re down to Telegram channel setup/pairing.

“Telegram not working” usually means one of these:

Telegram channel isn’t enabled / token not set
DM policy is pairing (default) and you haven’t approved the pairing yet
You’re messaging the bot but the Gateway isn’t receiving updates (token wrong / network)

1) Quick config check (redact token)

Make sure your ~/.openclaw/openclaw.json has something like:

{
  channels: {
    telegram: {
      enabled: true,

#

      botToken: "123:abc", // from @BotFather
      dmPolicy: "pairing"
    }
  }
}

(Important: the key is botToken, not token.)

Docs: https://docs.openclaw.ai/channels/telegram

2) See if Telegram is actually connected

Run:

#

openclaw channels status

3) Pairing flow (most common “it doesn’t reply” cause)

DM your Telegram bot “hi”
On the gateway host run:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Then DM again.

If it still doesn’t work

Paste the output of:

#

openclaw channels status
openclaw pairing list telegram

…and also run:

openclaw logs --follow

then DM the bot once, and paste the few log lines around the Telegram message (redact tokens). This will tell us immediately if the Gateway is receiving updates or if it’s blocked by config/pairing.

dire kite Mar 12, 2026, 11:29 AM

#

I can’t execute your Google-authenticated command context directly from this chat runtime.

So here is the exact one-liner that does exactly what you asked (create + print link immediately):

GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/home/openclaw/.config/gws/credentials.json gws sheets spreadsheets create --json '{"properties":{"title":"Demon Auto Sheet"}}' | jq -r '"https://docs.google.com/spreadsheets/d/\(.spreadsheetId)/edit"'

Run it and send me the link it prints — that confirms end-to-end is working.

my telegram

lucid coralBOT Mar 12, 2026, 11:31 AM

#

That Telegram reply is actually a useful clue: it means Telegram is working, but the agent running in that Telegram chat isn’t getting the exec tool, so it falls back to “I can’t run commands, here’s a one‑liner”.

This is not a gws problem anymore — it’s OpenClaw tool policy / agent routing / model tools for the Telegram session.

Quick fixes to try (in order)

1) Start a fresh Telegram session (so it reloads tool policy)

In Telegram, send as a standalone message:

/new

Then ask again.

2) Check if `exec` is being denied for Telegram’s agent/provider

On the gateway host, run:

#

openclaw config get tools
openclaw config get agents
openclaw channels status

Redact tokens, but paste the tools block + which agent Telegram is routed to.

Things to look for:

tools.profile accidentally set to minimal / messaging
tools.deny includes exec or group:runtime
tools.byProvider restricting tools for your current model/provider

3) Confirm exec is enabled (minimum config)

You want something like:

#

{
  tools: { profile: "full" } // or tools.allow includes "group:runtime" / "exec"
}

After changing config:

openclaw gateway restart

One question

When you DM from Telegram, are you sure it’s hitting the same agent you tested on the shell? (OpenClaw can route different channels to different agents, and tool policies can differ per agent.)

If you paste the output of openclaw channels status + your channels.telegram config block (redact the bot token), I can tell you exactly why that Telegram session doesn’t have exec.

dire kite Mar 12, 2026, 11:44 AM

#

{
"defaults": {
"model": {
"primary": "ollama/kimi-k2.5:cloud",
"fallbacks": [
"openai-codex/gpt-5.3-codex"
]
},
"models": {
"ollama/kimi-k2.5:cloud": {},
"anthropic/openai-codex": {},
"openai-codex/gpt-5.3-codex": {}
},
"workspace": "/home/openclaw/.openclaw/workspace",
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8
}
}
}

#

Gateway reachable.

Telegram default: enabled, configured, running, in:just now, out:1m ago, mode:polling, token:config

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

lucid coralBOT Mar 12, 2026, 11:45 AM

#

That explains the Telegram behavior.

Your default model is:

"primary": "ollama/kimi-k2.5:cloud"

A lot of non-Anthropic / non-“tool-native” models will not reliably do tool-calling, so instead of calling exec they’ll reply with “I can’t run commands here, run this one-liner”.

Quick test (no config changes)

In your Telegram chat, switch the session to your fallback tool-capable model, then try again:

Send:

/model openai-codex/gpt-5.3-codex

#

Then send:

/new

Then ask it to run your gws … command again.

If that works (recommended setup)

Keep kimi for normal chat, but create a separate “automation” agent whose primary model is the tool-capable one, and route Telegram to that agent (or just set the default primary model to the tool-capable one for now).

If you paste your tools block + channels.telegram block (redact tokens), I can point to the exact place to set “Telegram uses agent X”.

dire kite Mar 12, 2026, 11:45 AM

#

its codex now

lucid coralBOT Mar 12, 2026, 11:45 AM

#

Nice — that status output means Telegram itself is healthy (polling is working, gateway is receiving + sending messages).

So the remaining issue is almost certainly what we saw in your config: Telegram is using your default model (ollama/kimi-k2.5:cloud), and that model is behaving like “chat-only” (no tool calling), so it won’t actually invoke exec and will instead paste a one‑liner.

Do this in Telegram

Check what model the Telegram session is on:

/model status

Switch to your tool-capable fallback model:

/model openai-codex/gpt-5.3-codex

Start a fresh session so it stops “sticking” to the old behavior:

#

/new

Now ask it to run your gws … command again.

Make it permanent (optional)

If you want Telegram to always be able to run shell commands, set your primary model for that agent to the tool-capable one (keep kimi as a fallback/chat agent), then restart the gateway.

If you paste your current tools block + tell me whether /model openai-codex/gpt-5.3-codex succeeds or errors, I can give you the exact config tweak.

#

Great — now that Telegram is on Codex, it should actually start calling tools instead of pasting “run this one-liner”.

In Telegram, try this next:

Ask it:

Run gws drive files list --params '{"pageSize": 1}' and paste the JSON output.

If it runs: you’re done (Telegram → OpenClaw → exec → gws works).

If it replies with something like denied / approval required / allowlist, then you need to allow the gws binary for host exec:

which gws
openclaw approvals allowlist add --gateway "$(which gws)"

Then retry the Telegram request.

#

Send me what the Telegram bot replies when you ask it to run the gws drive files list … command (copy/paste), and I’ll tell you exactly which gate you’re hitting.

dire kite Mar 12, 2026, 11:48 AM

#

{
"files": [
{
"id": "1NiBoONAnSRccXspMhxVGBXkWqXmef7Uy1clf3CgcHJg",
"kind": "drive#file",
"mimeType": "application/vnd.google-apps.spreadsheet",
"name": "Gateway Env Test"
}
],
"incompleteSearch": false,
"kind": "drive#fileList",
"nextPageToken": "~!!~AI9FV7TFkre28Uw7IJbIUCPhYX28t0Tn0vanG46BXuQpAGpIFyrFBmyTVUdN48avRcctxTKO5yvOxEII5dPznKVAbLjdQ-4JMAjCyfQB-xDT7XCZcLuyZZ3y2L2Ewj7yGRQLbJ5TPnJfX_RqUZRTQH52VMaDvwaivLfPpn4bY6G8j9MpjQgXZRy1MovVgzPIICCRFdoDFfH1bmN875RgRc37pVY1ZnbHS0WnTv_Emhv5h3L7DL9B2CJXhOWUO_woUdY3Umg-s1NUY78tm-wKgCtEDGCfaTZXNnk2YySM1DEKhfgTsSYGRnSBWRPIlfDtrpE5owPzbeBfGCIX7umR95w5RFxF7iEf4w=="
}

this is what i got

lucid coralBOT Mar 12, 2026, 11:48 AM

#

Perfect — that JSON response means the whole pipeline is working now:

Telegram → OpenClaw → exec → gws (with GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE) → result back to Telegram.

If you want the “create sheet + return link” flow from Telegram, you can now ask:

“Create a spreadsheet titled Demon Auto Sheet and return the URL.”

Or explicitly:

gws sheets spreadsheets create --json '{"properties":{"title":"Demon Auto Sheet"}}' | jq -r '"https://docs.google.com/spreadsheets/d/\(.spreadsheetId)/edit"'

Two “keep it working” reminders:

Keep ~/.config/gws/credentials.json at chmod 600 and don’t set GOOGLE_WORKSPACE_CLI_TOKEN anymore.
If you don’t want to keep switching models manually, set your default model for that Telegram agent to Codex (or route Telegram to a “tools” agent).

#

If this solved your thread, please mark the solution so others can find it (right‑click the solution message → Apps → ✅ Mark Solution).

dire kite Mar 12, 2026, 11:50 AM

#

will this thread be deleted?

#

if there is any personal info remove it

lucid coralBOT Mar 12, 2026, 11:50 AM

#

OpenClaw won’t delete it.

Whether it disappears is up to Discord + this server’s settings:

Most help threads are kept, but they often get auto-archived after some inactivity (archived = not deleted; it’s just closed until someone posts again).
Mods/admins can delete threads manually, but that’s not automatic and I can’t guarantee what they’ll choose.

If you want it to stay useful for others, mark the solution (right‑click the solution message → Apps → ✅ Mark Solution).

#

The main personal/sensitive things I saw in this thread are:

Your Gmail address shown in the gws auth login success JSON ("account": "…@gmail.com").
A Google Sheets URL / spreadsheetId you generated (that link can be sensitive even if it still requires auth).
Minor: your Windows hostname (DESKTOP-…) and username (openclaw) in the shell prompt.

How to remove/redact it (fastest)

On Discord, edit or delete your own messages that contain those bits:

Hover message → … → Edit Message (replace email with <redacted>)
Or … → Delete Message

Do you want me to try deleting them for you?

I can try to delete the messages that contain:

the Gmail address line, and
the spreadsheet link

…but it depends on whether the bot has permission to delete user messages in this channel.

#

If you say “yes, delete them”, tell me which of these you want removed:

A) email address message
B) spreadsheet link message
C) both

(Also: you did the right thing by not pasting the exported credentials JSON contents — keep that private.)

dire kite Mar 12, 2026, 12:09 PM

#

Yes

lucid coralBOT Mar 12, 2026, 12:11 PM

#

Done — I deleted the two messages that contained your personal info:

the one with your Gmail address in the gws auth login output
the one that included the actual Google Sheets URL (spreadsheet link)

What’s still in the thread is just generic commands/templates (no tokens / no refresh-token JSON contents).

If you ever pasted a Telegram bot token or the contents of credentials.json anywhere (even briefly), rotate/revoke it — but from what I saw, you didn’t paste those secrets.

dire kite Mar 12, 2026, 12:11 PM

#

Thanks

#Not able to run google workspace automatically

1) Check what error you get

2) Enable shell/command tools (exec)

3) Make sure the CLI is installed on the right machine

Tool allowlist ≠ “allowed to run any command”

What to do (pick one)

Option A (recommended): keep allowlist, turn prompts back on

Option B (quick + unsafe): set full exec

Also check: is the CLI installed on the gateway machine?

1) Set up Telegram channel

2) Restart gateway + approve your DM

3) Important for your CLI automation

1) First: fix the command (you have an extra {)

2) Check if you have a bad token env var set (common on Windows/WSL)

3) Re-auth the “normal” way (recommended for automation)

4) If you do need GOOGLE_WORKSPACE_CLI_TOKEN, strip Windows CR

Do these 3 quick checks

Next: test the exact Sheets call again

Two important notes (so it keeps working under OpenClaw service)

If the gws ... create command now works, but OpenClaw still can’t run it

Quick isolation test (takes 10 seconds)

If it works from /tmp

Also run this (safe + helpful)

1) Show the relevant env (redact values)

2) Quick test: temporarily disable proxy + token env vars

3) If it still fails, grab version + backtrace (to report upstream)

1) Why you got the “failed to parse header value” (the 500)

Fix: remove that env var permanently

2) Why you now get “Failed to decrypt credentials” (401)

Fix: logout + clean creds + login again (with the token env var NOT set)

If you want the most reliable automation for OpenClaw + Telegram

The fix: force gws to use the .encryption_key file backend

Important: remove the bad token env var permanently

If GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND doesn’t work

Goal

Do this (copy/paste)

Then tell me what happens

Do this exactly (forces file backend for this run)

Quick sanity checks (tell me these outputs)

Why this is WSL-related

Do this exactly

What would cause this in practice

The fix (one more time, minimal)

The key point

Do this exactly (one clean run)

If it still fails after that, I need 2 outputs

1) Create a brand new credentials.enc (don’t change .encryption_key)

2) Immediately test decryption without calling Google APIs

If auth export fails too

If auth export works

Fastest workaround (and best for OpenClaw automation):

Then for OpenClaw + Telegram

Best workaround (you already proved it works): use plaintext credentials file

Then wire it into OpenClaw (Telegram automation)

0) First, remove the broken env override (important)

1) Downgrade gws to 0.9.0

2) Reset gws auth files + re-login

3) Test

Check the JSON keys only (safe to paste)

Regenerate the credentials file cleanly

Fix: regenerate a real credentials.json (somewhere persistent)

What to do next so OpenClaw (Telegram) can run it too

1) Quick config check (redact token)

2) See if Telegram is actually connected

3) Pairing flow (most common “it doesn’t reply” cause)

If it still doesn’t work

Quick fixes to try (in order)

1) Start a fresh Telegram session (so it reloads tool policy)

2) Check if exec is being denied for Telegram’s agent/provider

3) Confirm exec is enabled (minimum config)

One question

Quick test (no config changes)

If that works (recommended setup)

Do this in Telegram

Make it permanent (optional)

How to remove/redact it (fastest)

Do you want me to try deleting them for you?

2) Enable shell/command tools (`exec`)

1) First: fix the command (you have an extra `{`)

4) If you do need `GOOGLE_WORKSPACE_CLI_TOKEN`, strip Windows CR

If the `gws ... create` command now works, but OpenClaw still can’t run it

If it works from `/tmp`

The fix: force gws to use the `.encryption_key` file backend

If `GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND` doesn’t work

1) Create a brand new `credentials.enc` (don’t change `.encryption_key`)

If `auth export` fails too

If `auth export` works

1) Downgrade `gws` to 0.9.0

2) Check if `exec` is being denied for Telegram’s agent/provider