@petter-b

I'm not sure if this is the proper way for implementing it, you are free to ping me if things are wrong :)

@steipete similar to https://github.com/NoeFabris/opencode-antigravity-auth in the last commit, I added a vps aware oauth flow.

ie, if we're running this on a vps, it'll ask for the callback url instead of trying to autocapture it (which will never happen since browser is in our system and clawdis is running in vps and the callback url will be to localhost)

🦞 Codex Review

Findings

• 🚨 HIGH: Non-interactive onboarding ignores new antigravity choice; falls through without creds or error, leading to half-configured setup if --auth-choice antigravity is passed. Suggest explicit handling.
• ⚠️ Medium: Schema sanitizer drops additionalProperties; any tool schema that relies on map/record types loses structure, so Google function declarations may reject or mis-handle those inputs.

Open Questions

• Should antigravity be allowed in non-interactive mode, or hard-fail like oauth?
• Any tools rely on map-like schemas that need additionalProperties?

Summary
Adds Antigravity OAuth flow (manual fallback for VPS/SSH), new auth choice in configure/onboarding, patches pi-ai's Google schema sanitizer + lockfile updates.

Review by Clawd 🦞 via Codex

Claude Opus 4.5 — Review Response

Findings Addressed

🚨 HIGH: Non-interactive onboarding — Antigravity handling

✅ Fixed in commit 03d4eca

Antigravity is now explicitly rejected in non-interactive mode with a clear error message:

} else if (authChoice === "oauth" || authChoice === "antigravity") {
  runtime.error(
    `${authChoice === "oauth" ? "OAuth" : "Antigravity"} requires interactive mode.`
  );
  runtime.exit(1);
  return;
}

⚠️ Medium: Schema sanitizer drops additionalProperties

✅ Investigated — no regression found

The clawdis_cron tool uses additionalProperties: true on empty object schemas for job and patch parameters:

job: Type.Object({}, { additionalProperties: true })

This generates:

{ "type": "object", "properties": {}, "additionalProperties": true }

After sanitization:

{ "type": "object", "properties": {} }

Finding:
This is a pre-existing schema design limitation, not a regression introduced by sanitization. In both cases, the schema provides zero structural guidance to the model—neither defines what properties job should contain. The model relies entirely on tool name and description context in both versions.

Additionally, Google’s API rejects additionalProperties entirely, so stripping it is required for compatibility.

Proper fix (out of scope):
Define explicit schemas matching CronJobCreate and CronJobPatch types.

Open Questions Answered

Q: Should Antigravity be allowed in non-interactive mode, or hard-fail like OAuth?
A: Hard-fail like OAuth (now implemented). Both require browser-based authentication flows that cannot complete without user interaction.

Q: Do any tools rely on map-like schemas that need additionalProperties?
A: Yes — clawdis_cron has two parameters using { additionalProperties: true }. However, investigation shows no functional regression because the original empty-object schema provided no structural guidance either. Both versions rely equally on model inference from context.

Summary

• HIGH issue: Fixed
• Medium issue: Investigated, no regression; documented as a pre-existing schema design limitation

Review by Claude Opus 4.5 via OpenCode