gogcli hook fails

[Arjun31415]

I have configured openclaw with gogcli to read emails. I am testing only the hook part right now. The google cloud console is completely setup and I see the pub/sub pushes and ACKs being sent.

However, I get hook 404, and I am not sure what is wrong with my config.

  programs.openclaw = {
    enable = true;
    bundledPlugins = {
      summarize.enable = true; # Summarize web pages, PDFs, videos
      gogcli.enable = true;
      discrawl.enable = false; # Discord archive/search
      wacrawl.enable = false; # WhatsApp archive/search
      peekaboo.enable = false; # Take screenshots
      poltergeist.enable = false; # File watching and automation
      sag.enable = false; # Text-to-speech
      camsnap.enable = false; # Camera snapshots
      goplaces.enable = false; # Google Places API
      sonoscli.enable = false; # Sonos control
      imsg.enable = false; # iMessage
    };
    # Pure declarative config matching official OpenClaw specifications
    config = {
      gateway = {
        mode = "local";
        auth = {
          token = "openclaw-gateway-token"; # or set OPENCLAW_GATEWAY_TOKEN
        };
        port = 18789;
      };
      hooks = {
        enabled = true;
        path = "/hooks";
        token = "openclaw-hooks-token";
        allowedSessionKeyPrefixes = ["gmail-" "hook:"];
        presets = ["gmail"];
        gmail = {
          account = "<account-name>";
          topic = "<topic-name>";
          pushToken = "<token from google cloud>";
          serve = {
            bind = "127.0.0.1";
            port = 8788;
            path = "/gmail-pubsub";
          };
          hookUrl = "http://127.0.0.1:18789/hooks/gmail";
        };
      };
      agents = {
        defaults = {
          model = {
            primary = "local/gemma-4"; # Formatted as provider_id/model_id
          };
        };
      };
      models = {
        mode = "merge";
        providers = {
          local = {
            baseUrl = "http://127.0.0.1:8080/v1"; # Your llama.cpp instance location
            apiKey = "local-ai"; # Local token placeholder to satisfy strict JSON validation
            api = "openai-completions"; # Directs OpenClaw to leverage standard OpenAI API layout
            models = [
              {
                id = "gemma-4";
                name = "Gemma 4 E4B";
              }
            ];
          };
        };
      };
  systemd.user.services.openclaw-funnel = {
    Unit = {
      Description = "Tailscale Funnel pointing to Gog Receiver";
      After = ["network.target"];
    };

    Service = {
      ExecStart = "${pkgs.tailscale}/bin/tailscale funnel 8788";
      Restart = "always";
      RestartSec = 5;
    };

    Install = {
      WantedBy = ["default.target"];
    };
  };

when i run the gateway manually -

openclaw gateway run 



12:29:16 [gmail-watcher] watch started for <email>
12:29:16 [gmail-watcher] starting gog gmail watch serve --account <email> --bind 127.0.0.1 --port 8788 --path /gmail-pubsub --include-body --max-bytes 20000
12:29:16 [gmail-watcher] gmail watcher started for <email> (renew every 720m)
12:29:16 [hooks] gmail watcher started
12:29:16 [gmail-watcher] [gog] watch: listening on 127.0.0.1:8788/gmail-pubsub
12:29:17 [gateway] provider auth state pre-warmed in 1201ms eventLoopMax=157.3ms
12:31:23 [gmail-watcher] [gog] watch: ignoring stale push historyId=6662312 (stored=6662379)
12:31:23 [gmail-watcher] [gog] watch: ignoring stale push historyId=6662247 (stored=6662379)
12:31:24 [gmail-watcher] [gog] watch: ignoring stale push historyId=6662379 (stored=6662445)
12:31:25 [gmail-watcher] [gog] watch: ignoring stale push historyId=6662445 (stored=6662461)

12:39:45 [gmail-watcher] [gog] watch: hook failed: hook status 400

I always get hook status 400.

Any help is appreciated.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 2, 2026, 6:54 AM ET / 10:54 UTC.

Summary
Keep open. Current nix-openclaw main packages OpenClaw v2026.5.28, where the Gmail preset renders a templated hook:gmail session key and mapped hook dispatch returns 400 unless hooks.allowRequestSessionKey=true; the reporter's Nix config has prefixes but not that gate, and the upstream policy repair is still unresolved.

Reproducibility: yes. at source level: the reporter's config enables the Gmail preset and constrained prefixes but omits hooks.allowRequestSessionKey, while the pinned upstream handler returns 400 for templated mapped session keys in that state. I did not run a live Gmail Pub/Sub setup in this read-only review.

Next step
Manual review is needed because the narrow symptom is source-reproducible, but the fix should follow the upstream security-sensitive Gmail hook session-policy decision instead of an autonomous nix-openclaw-only default change.

Review details

Best possible solution:

Coordinate with the upstream Gmail hook policy fix, then update nix-openclaw's pin and README/Nix setup guidance so Gmail Pub/Sub uses one bounded, documented session policy end to end.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: the reporter's config enables the Gmail preset and constrained prefixes but omits hooks.allowRequestSessionKey, while the pinned upstream handler returns 400 for templated mapped session keys in that state. I did not run a live Gmail Pub/Sub setup in this read-only review.

Is this the best way to solve the issue?

Unclear as an immediate target-repo fix: adding allowRequestSessionKey=true with bounded prefixes explains the reporter's 400, but maintainers should align with the upstream decision on per-message Gmail sessions versus a static-session mapping before changing nix-openclaw defaults or docs.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Gmail Pub/Sub roundtrip was run in this read-only pass, so there may be additional watcher, Google Cloud, or local model-provider failures after the source-level 400 is fixed.
• The correct default is security-sensitive because enabling templated Gmail session keys lets webhook payload data influence session routing unless constrained by prefixes or replaced with a static mapping.
• The most relevant repair is upstream in openclaw/openclaw, so a nix-openclaw-only fix should avoid creating a competing behavior before the upstream policy is settled.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9a06fba241fa.

Label changes

Label changes:

• add P2: This is a normal-priority integration bug affecting a bounded Gmail hook workflow rather than the core OpenClaw runtime for all users.
• add impact:message-loss: The reported Gmail Pub/Sub pushes reach gogcli but are rejected before producing the expected OpenClaw hook work.
• add impact:session-state: The failing path is the Gmail preset's per-message hook:gmail session routing policy.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority integration bug affecting a bounded Gmail hook workflow rather than the core OpenClaw runtime for all users.
• impact:message-loss: The reported Gmail Pub/Sub pushes reach gogcli but are rejected before producing the expected OpenClaw hook work.
• impact:session-state: The failing path is the Gmail preset's per-message hook:gmail session routing policy.

Evidence reviewed

What I checked:

• Repository policy read: The root policy routes consumer OpenClaw setup through README.md and says public packaging bugs should be fixed in this repository, so this Nix-hosted Gmail hook report is in scope for maintainer triage. (AGENTS.md:24, 9a06fba241fa)
• Pinned OpenClaw version: nix-openclaw currently packages OpenClaw v2026.5.28 at upstream commit e93216080aa1f425d3ab127014603eba8e365b2d. (nix/sources/openclaw-source.nix:9, 9a06fba241fa)
• Nix config surface exposes the relevant hook options: The generated Nix options include hooks.allowRequestSessionKey, hooks.allowedSessionKeyPrefixes, and the hooks.gmail fields used by the reporter, so this config is passed through rather than rejected by the module layer. (nix/generated/openclaw-config-options.nix:4835, 9a06fba241fa)
• Gmail preset uses a templated session key: The pinned upstream Gmail preset maps /hooks/gmail to an agent action with sessionKey: "hook:gmail:{{messages[0].id}}", making per-message session routing depend on templated hook policy. (src/gateway/hooks-mapping.ts:72, aeb54555558c)
• Templated mapping keys are gated: Upstream hook session resolution denies mapping-templated session keys when hooks.allowRequestSessionKey is not enabled, matching the missing field in the reporter's config. (src/gateway/hooks.ts:331, 5275d008ed33)
• Mapped hook rejection returns 400: The pinned upstream request handler sends HTTP 400 when resolveHookSessionKey rejects a mapped hook action, which matches the reported hook status 400 symptom. (src/gateway/server/hooks-request-handler.ts:373, a494eea6d40f)

Likely related people:

• pgondhi987: Authored the merged upstream change that made template-rendered mapping session keys obey hooks.allowRequestSessionKey, which is the gate producing the 400 for this config. (role: introduced session-policy behavior; confidence: high; commits: 5275d008ed33; files: src/gateway/hooks.ts, src/gateway/hooks-mapping.ts, src/gateway/server/hooks-request-handler.ts)
• steipete: Upstream history maps both the Gmail hooks wizard and the Gmail preset mapping to this account, which is central to the setup side of the mismatch. (role: introduced Gmail hook setup and mapping behavior; confidence: high; commits: 523d9ec3c2e4, aeb54555558c; files: src/hooks/gmail-ops.ts, src/hooks/gmail.ts, src/gateway/hooks-mapping.ts)
• vincentkoc: Recent upstream hook request-handler work touches the mapped-hook runtime boundary that turns the rejected session key into a 400 response. (role: adjacent gateway hooks contributor; confidence: medium; commits: a494eea6d40f; files: src/gateway/server/hooks-request-handler.ts)
• joshp123: Updated nix-openclaw to package OpenClaw v2026.5.28 and refreshed the generated config options now involved in this report. (role: recent nix package pin contributor; confidence: medium; commits: 9bd2b9f299b4; files: nix/sources/openclaw-source.nix, nix/generated/openclaw-config-options.nix)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[Arjun31415]

Ok adding

hooks.allowRequestSessionKey=true;

Fixed it.

It would be nice to have this documented somewhere, because I could not find it in official openclaw docs, it just says run the gogcli subcommand through openclaw and it will configure everything for you, which does not work for NixOS

[joshp123]

working on this in openclaw/rfcs#8 openclaw/gogcli#700 openclaw/openclaw#90723

tl;dr is that if you have the pull model this makes this a lot simpler, hence adding the pull model first, then building it in to nix-openclaw

[joshp123]

we'll also try and make this a first-class-citizen in nix-openclaw so you dont need as much config either