OpenClaw + gws Google Auth Issue (Edits created but invisible in Drive)

[stray quest]

Setup done:

• gws CLI + client_secret.json on server
• Ran full OAuth on Mac (npx @googleworkspace/cli auth login + export)
• SCP’d credentials.json to /root/.config/gws/credentials.json
• gws auth status = perfect (oauth2, token_valid=true, full Drive/Docs/Sheets scopes, correct user)

Current problem:

• Agent replies “Doc created” + ID + content
• File never appears in Google Drive
• Agent replies "Edits made" + ID + content
  -Edits never appears in Google Doc. Agent can read Doc fine.
• Manual gws drive files create --upload works instantly from shell

Tried:

• Temporary export GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=… + openclaw gateway restart (works only in that terminal)
• Started systemctl --user edit openclaw-gateway to add permanent Environment= line (user stopped because override.conf looked scary)

Systemd user service (openclaw-gateway) isn’t picking up the env var. How do we make the credential path permanent without wiping the override file?

(Full gws auth status and service file available if needed)

[magic hatch]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[karmic marsh]

For systemd user services, the clean way is a drop-in override — it does not replace the main unit, and it won’t wipe anything unless you use --full.

You’ve got 3 good options (in order of “least systemd-fiddly”):

Option A (best): put credentials.json where the service user expects it

A systemctl --user service runs as that user, so /root/.config/... usually won’t be readable/used.

Put the file here for the same user that runs the gateway:

• ~/.config/gws/credentials.json

Then you don’t need GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE at all.

Option B: set it in OpenClaw’s global env file (service-safe)

OpenClaw loads ~/.openclaw/.env even when started by systemd (so it won’t “work only in that terminal” anymore):

mkdir -p ~/.openclaw
nano ~/.openclaw/.env

Add:

GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=/absolute/path/to/credentials.json

Then:

systemctl --user restart openclaw-gateway

Docs: https://docs.openclaw.ai/help/faq#env-vars-and-env-loading

Option C: systemd drop-in override (what you were about to do)

1. Edit the drop-in (safe; no wipe):

systemctl --user edit openclaw-gateway

2. Paste only this:

[Service]
Environment="GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE=%h/.config/gws/credentials.json"

(Use your real absolute path if you’re not using %h.)

3. Reload + restart:

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway

4. Verify systemd sees it:

systemctl --user show openclaw-gateway -p Environment

---

If after this you still see “Doc created / edits made” but nothing appears in Drive, paste:

• openclaw --version
• systemctl --user status openclaw-gateway
• the relevant journalctl --user -u openclaw-gateway -n 200 --no-pager chunk around a create/edit attempt

Because that symptom pattern is very consistent with “gateway service is running under a different user / different env, so it’s using different (or no) gws credentials than your shell.”

[stray quest]

Still seeing Doc created/edits made; doc appears in drive but empty of content.

=== 1. openclaw --version ===
OpenClaw 2026.3.8 (3caab92)

=== 2. systemctl --user status openclaw-gateway ===
● openclaw-gateway.service - OpenClaw Gateway (v2026.3.8)
Loaded: loaded (/root/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Wed 2026-03-11 07:17:30 PDT; 1h 6min ago
Main PID: 1134414 (openclaw-gatewa)
Tasks: 13 (limit: 4653)
Memory: 600.5M (peak: 749.9M)
CPU: 56.328s
CGroup: /user.slice/user-0.slice/[e-mail]/app.slice/openclaw-gateway.service
└─1134414 openclaw-gateway

=== 3. journalctl --user -u openclaw-gateway --since "10 minutes ago" -n 300 ===
Mar 11 08:17:40 ubuntu-s-2vcpu-4gb-sfo2-01 node[1134414]: 2026-03-11T08:17:40.371-07:00 [skills] Skipping skill path that resolves outside its configured root.
Mar 11 08:17:45 ubuntu-s-2vcpu-4gb-sfo2-01 node[1134414]: 2026-03-11T08:17:45.712-07:00 [gateway] memory-lancedb: injecting 3 memories into context
Mar 11 08:17:45 ubuntu-s-2vcpu-4gb-sfo2-01 node[1134414]: 2026-03-11T08:17:45.880-07:00 [agent/embedded] embedded run agent end: runId=8fcfc864-b7f7-45ec-9692-8c89a5b67e66 isError=true error=LLM request rejected: You have reached your specified API usage limits. You will regain access on 2026-04-01 at 00:00 UTC.
Mar 11 08:17:45 ubuntu-s-2vcpu-4gb-sfo2-01 node[1134414]: 2026-03-11T08:17:45.896-07:00 [diagnostic] lane task error: lane=main durationMs=5432 error="FailoverError: LLM request rejected: You have reached your specified API usage limits. You will regain access on 2026-04-01 at 00:00 UTC."
... (continues with identical rate-limit spam for the next several minutes)
Mar 11 08:24:08 ubuntu-s-2vcpu-4gb-sfo2-01 node[1134414]: 2026-03-11T08:24:08.566-07:00 [telegram] sendMessage ok chat=8480360593 message=5995

[karmic marsh]

You’ve basically moved past the “service env var not applied” problem (the doc showing up in Drive means the gateway is now running with some working creds), but the “doc exists but content never shows up” points to a different issue:

1) Your gateway logs show the agent is currently not reliable at all

This line is the smoking gun:

LLM request rejected: You have reached your specified API usage limits ... regain access on 2026-04-01

When the model is hard-rejecting like that, the agent will often still say “created/edited” without actually completing tool calls.

Action:

• Run and paste: openclaw models status
• Fix the provider/key/limits so runs aren’t being rejected (otherwise anything after that is basically random).

2) “Doc created” often means “empty Google Doc created” (normal) — writing requires Docs API (batchUpdate)

Creating a Google Doc via Drive (or docs documents create) produces an empty doc. To put text in it you must do a Docs API batchUpdate insertText. A very common failure mode is that the agent is doing a Drive files.update --upload (works for binaries) which does not update Google Docs content.

Quick sanity test from the same user the service runs as (root, in your case):

gws docs documents create --requestBody '{"title":"oc-test"}'
# take the documentId, then:
gws docs documents batchUpdate --documentId <ID> \
--requestBody '{"requests":[{"insertText":{"location":{"index":1},"text":"hello from gws\n"}}]}'

If that works: the issue is simply that the agent/tooling is using the wrong write mechanism (Drive upload/update instead of Docs batchUpdate).

3) Next thing I need: what command is OpenClaw actually running?

Please paste the log lines for a single “write to doc” attempt that include the exec/tool command (usually you’ll see something like tool=exec or the actual gws ... command line in openclaw logs --follow).

Right now the snippet you posted is only rate-limit spam, so we can’t see whether it’s calling:

• gws drive files update ... (won’t change doc text), or
• gws docs documents batchUpdate ... (the correct way)

Once we see the exact command, we can tell you the minimal fix.

[stray quest]

Updated logs after switching to API key + agent confirms “verified via gws docs documents get”
(Agent said “Doc created” + ID + “Edits made” and claims the text is there, but no doc now appearing.). Agent confirms it is using the process in your #2 section above.

=== 3. journalctl --user -u openclaw-gateway --since "10 minutes ago" -n 300 ===
Mar 11 10:43:12 ubuntu-s-2vcpu-4gb-sfo2-01 node[1139072]: 2026-03-11T10:43:12.354-07:00 [skills] Skipping skill path that resolves outside its configured root.
Mar 11 10:43:14 ubuntu-s-2vcpu-4gb-sfo2-01 node[1139072]: 2026-03-11T10:43:14.122-07:00 [gateway] memory-lancedb: injecting 3 memories into context
Mar 11 10:43:18 ubuntu-s-2vcpu-4gb-sfo2-01 node[1139072]: 2026-03-11T10:43:18.906-07:00 [telegram] sendMessage ok chat=8480360593 message=6018
... (continues with only memory injection, telegram messages, and skill skipping)
Mar 11 10:50:56 ubuntu-s-2vcpu-4gb-sfo2-01 node[1139072]: 2026-03-11T10:50:56.341-07:00 [telegram] sendMessage ok chat=8480360593 message=6034

Important update:

Switched agent from Anthropic (Claude.ai subscription) to Anthropic via real API key.
Agent now says it verified the content with gws docs documents get (step 2 you mentioned) and claims success.
But the journalctl logs still contain ZERO gws activity — no drive files create, no docs +write, no tool calls at all.

The agent is claiming it ran the tools and verified the text, but the logs show the agent never actually called them. Manual gws test script (create + write) still works perfectly every time.
Should I:
A) Regenerate skills (gws generate-skills) and restart the gateway?
B) Enable verbose tool logging somehow?
C) Provide the Document ID + full agent message from the last attempt?
Happy to run whatever you need next!

[karmic marsh]

The “ZERO gws activity in journalctl” is very likely a log source mismatch, not proof that no tools ran.

By default the gateway writes its real structured logs to a file (JSONL), and journalctl only shows the service stdout/stderr (which can be pretty minimal).

Do this next (this is your “B”, basically)

1. Tail the actual gateway log stream:

openclaw logs --follow

2. In another window, trigger one “create doc + write text” attempt.

3. In the openclaw logs output, you should see tool activity (exec/tool summaries). If you want it machine-searchable:

openclaw logs --follow --json

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

If tool lines still don’t show up: crank verbosity for one run

Set log level for the service (easy way is ~/.openclaw/.env, since you’re running as root user service):

/root/.openclaw/.env

OPENCLAW_LOG_LEVEL=debug

Restart:

systemctl --user restart openclaw-gateway

(Env var is documented: https://docs.openclaw.ai/logging#log-levels)

Two quick sanity checks (because this can still be “no tools are being called”)

• In chat, send:

• /exec (shows current exec defaults)

• and make sure it’s not stuck on host=sandbox if your gws lives on the gateway host. Forcing it is:

• /exec host=gateway
  Docs: https://docs.openclaw.ai/tools/exec

• Run:

openclaw doctor

and look for any warnings about tool policy / allowlists (exec denied, unknown tools.allow entries, etc.).

About A/C

• A (regenerate skills): I wouldn’t do this yet. You already have manual gws working; we first need to see what OpenClaw is actually executing (or failing to execute).
• C (doc id + agent message): useful later, but only after we confirm there are real tool calls + their exact command/response.