Bug Description

Related to #411
Fresh OAuth setup via the Hermes google-workspace skill writes ~/.hermes/google_token.json without a "type" field.

That token is accepted by Hermes' Python auth check and Python Google client path, but it is not accepted by the gws-backed runtime path. When gws is available, google_api.py appears to prefer it, and gws fails on the fresh token because "type" is missing.

Later, during a normal Gmail operation, the same token file may be rewritten and gain:

"type": "authorized_user"

After that, Gmail operations begin working again through the gws path.

This creates an inconsistent auth state:

1. setup.py --auth-code writes a token that Hermes/Python accepts
2. google_api.py prefers gws when available
3. gws rejects the freshly written token because "type" is missing
4. a later runtime flow appears to rewrite/normalize the token and add "type"

Steps to Reproduce

1. Ensure gws is installed and available on PATH
2. Run a fresh Hermes Google Workspace auth flow:

   python ~/.hermes/skills/productivity/google-workspace/scripts/setup.py --auth-url
   python ~/.hermes/skills/productivity/google-workspace/scripts/setup.py --auth-code "<redacted redirect URL>"

3. Inspect ~/.hermes/google_token.json
4. Observe that the token does not contain "type"
5. Run:

   python ~/.hermes/skills/productivity/google-workspace/scripts/setup.py --check

6. Observe that auth check succeeds
7. Run a Gmail operation through the runtime path:

   python ~/.hermes/skills/productivity/google-workspace/scripts/google_api.py gmail search "in:inbox" --max 5

8. Observe failure from the gws path complaining about missing "type" (at least before a later normalization occurs)

Expected Behavior

The token written by the official Hermes Google Workspace auth flow should be immediately usable by the same runtime path Hermes uses when gws is installed.

Specifically:

• setup.py --auth-code should write a token schema compatible with both Hermes/Python and gws
• token schema should be stable immediately after auth
• a later Gmail operation should not be required to "fix" the token

Actual Behavior

• setup.py --auth-code writes ~/.hermes/google_token.json
• the fresh token does not contain "type"
• setup.py --check reports success
• Python Google client usage works
• gws-backed Gmail usage fails on the missing field
• later, a Gmail runtime flow rewrites the token and it then contains:

  "type": "authorized_user"

• after that later rewrite, Gmail operations start working again

the rewrite is where things are very uncertain as the agent may or may not do it, and might corrupt the token also

Observed failure from the gws path:

Failed to parse authorized user credentials ... missing field 'type'

Observed auth success:

AUTHENTICATED: Token valid at ~/.hermes/google_token.json

Affected Component

Skills (skill loading, skill hub, skill guard)

Messaging Platform (if gateway-related)

No response

Debug Report

Report       https://paste.rs/pChh3
agent.log    https://paste.rs/x4qHq
gateway.log  https://paste.rs/X3Zrf

Operating System

ubuntu 24.04

Python Version

3.11.14

Hermes Version

v0.9.0 (2026.4.13)

Additional Logs / Traceback (optional)

Relevant environment details:


gws 0.22.5
Node v22.22.2
npm 11.12.0
google-api-python-client 2.193.0
google-auth-oauthlib 1.3.1
google-auth-httplib2 0.3.1
google-auth 2.49.1
oauthlib 3.3.1
requests-oauthlib 2.0.0


Observed timeline from a local watcher around auth/runtime:


fresh auth wrote token at 2026-04-16 06:21:46Z
token at that point had no "type"
later a Gmail search ran through google_api.py
token changed again at 2026-04-16 06:27:08Z
after that rewrite, token contained "type": "authorized_user"


There was no separate manual token-edit command observed in that window; the `"type"` field appeared during a later runtime Gmail flow, not during `--auth-code` itself.

Root Cause Analysis (optional)

This looks like a token schema mismatch between the auth-writing path and the gws-reading path.

Based on local investigation:

• ~/.hermes/skills/productivity/google-workspace/scripts/setup.py writes a fresh token that works for Hermes/Python auth checks
• ~/.hermes/skills/productivity/google-workspace/scripts/google_api.py prefers gws when available
• gws expects an authorized-user credential object that includes:

  "type": "authorized_user"

• the fresh Hermes-written token omits that field
• a later runtime flow appears to rewrite/normalize the token so that gws accepts it

So the core issue appears to be:

1. auth setup writes one token shape
2. runtime with gws expects a different token shape
3. later runtime behavior may silently normalize the token, making the problem appear flaky

Separate but related: some cron wrappers in this environment swallowed backend failures and returned [SILENT], which made the auth/runtime problem much harder to diagnose. That may be a separate bug, but it amplified the confusion.

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR