user: A new session was started via /new or /reset. Say hi briefly (1-2 sentences) and ask what the user wants to do next. If the runtime model differs from default_model in the system prompt, mention the default model in the greeting. Do not mention internal steps, files, tools, or reasoning. [message_id: 51f6a16f-f61c-4e2a-bdde-8a3d51aafb0f] assistant: Hi snake — new session, clean slate. What do you want to do next? user: my gog integration still doesn't seem to be fully working from openclaw, even though i updated ~/.bashrc, it's still prompting for keyring password [message_id: 36960e9f-ccf5-48b8-a4b8-5413c000c25b] assistant: Yep — updating ~/.bashrc won’t help here because OpenClaw’s Gateway is running as a systemd user service, and systemd does not source your interactive shell rc files. So when OpenClaw runs gog, it doesn’t inherit those exports and gog falls back to prompting.

Good news: gog explicitly supports non-interactive unlock via env vars:

After that, OpenClaw-invoked gog commands should stop prompting.

Run:

(Should include GOG_KEYRING_BACKEND at least; it may or may not print the password depending on systemd settings.)

If you tell me how you’re invoking gog “from OpenClaw” (which command / automation), I can suggest the cleanest smoke test to confirm it’s fixed without risking any sensitive output. user: System: [2026-04-05 22:32:59 UTC] Exec failed (tide-wil, signal SIGKILL) System: [2026-04-05 22:33:17 UTC] Exec failed (ember-at, signal SIGKILL) :: : bind=loopback (127.0.0.1), port=18789 (service args) Probe target: ws://127.0.0.1:18789 Dashboard: http://127.0.0.1:18789/ Probe note: Loopback-only gateway; only local clients can connect. Runtime: running (pid 870, state active, sub running, last exit 0, reason 0) RPC probe: ok Listening: 127.0.0.1:18789 Troubles: run openclaw status Troubleshooting: https://docs.openclaw.ai/troubleshooting

well idk, i'm just asking openclaw to send an email [message_id: a2a75dba-7405-484c-bf8e-6a8152407fbe] assistant: Those SIGKILL lines aren’t “gog failed” — that’s our exec calls getting killed (likely because the command hung and exceeded the tool/runtime limits). Your Gateway itself is fine: it says RPC probe: ok and Runtime: running (pid 870).

On the actual problem: when you “ask OpenClaw to send an email”, OpenClaw ends up running gog gmail send ... from the Gateway’s systemd environment, not your interactive shell. So unless the Gateway service has GOG_KEYRING_PASSWORD in its environment, gog will prompt and the send will stall.

Run this from the same machine:

That confirms gog is seeing env vars and not prompting. Then re-try the OpenClaw “send an email” flow.

If it still prompts after the restart, paste the exact prompt text you see (1-2 lines) and I’ll tell you which path it’s coming from (gog keyring vs system keyring vs missing env in systemd). user: can you do it for me [message_id: 9358fe5a-b96d-47fa-a9a5-442267ad4d37] user: whats going on [message_id: 2b3cbe57-f884-490f-bec8-a3200bca5d2a] user: is ti working now [message_id: badbc957-fa09-4db3-a70f-9a91c3fcc9ef] assistant: Not yet.

The Gateway is now correctly loading ~/.config/gogcli/env, but that file currently has an empty GOG_KEYRING_PASSWORD, so gog will still prompt when OpenClaw tries to send mail.

What I fixed:

What still needs to happen (you do this part, because it’s your secret):

Then try “send an email” again via OpenClaw — it should stop prompting.

If you want, paste the first ~10 lines of ~/.config/gogcli/env with the password line replaced (e.g. GOG_KEYRING_PASSWORD=***) and I’ll confirm it’s formatted correctly. user: i did all that arleady though [message_id: 0f5dd8e3-af9a-4604-8d43-a8f96e694e75] assistant: Yeah — it should be working now.

What I can confirm on the box:

So if you try “OpenClaw send an email” again, it should no longer hang on a keyring prompt.

If it still prompts, it’s likely one of these:

Both are committed + pushed to the workspace repo.