I've been working on ExtraSuite - a cli for working with google workspace files, but more specifically google docs. See

Google docs batchUpdate is complex for an agent to get right. Simple edits are fine, but anything complex and the agent struggles. Google workspace client / gogcli don't provide much help. They can create google docs from markdown, but edits are fairly limited.

ExtraSuite treat the google docs as a folder of markdown files. The agent edits markdown files locally, ExtraSuite then reconciles the google doc.

The cli provides two commands - push and pull.

'pull' - takes the url for a google docs and downloads it as markdown files, 1 per tab. It also creates an index.md with table of contents from each tab. And more importantly, it maintains meta data about the google doc in a dot folder.

Claude code can then edit the markdown files as per your instructions. Add/modify content. Add new markdown files to create new tabs. Tables and images and lists are all supported. GIthub flavoured markdown is supported. This works for new content as well as modifying existing content.

Then claude code calls the 'push' command. Push is a multi step process, and claude code doesnt need to know any of it.

1. It identifies what claude code changed

2. Then it applies those changes on to the base version of google doc

3. Then it figures out how to reconcile the live google document using the batchUpdate api.

In this process, the cli ensures anything that cant be represented in markdown is left as is. This means that styles, fonts, table of contents etc. dont mess up.

One more key feature is support for comments. Leave comments in google docs. Claude can read those comments and fix the document and also respond to those comments. Treat comments like a task list.

We have been using this internally for several months now. Saves us a lot of tokens compared to gws or gogcli. In general, complex edits to the google doc are possible using fewer tokens and cheaper models - because any model can edit markdown.

If you have gogcli or gws configured, extrasuite should be able to reuse whatever auth you have already configured.

Try it out and would love any feedback. The cli is open source.

It feels trivial, but I miss the productivity sound from other apps and would love to figure out a way to build in a chime/task completed sound when I check off something in google tasks showing up on my calendar.

I built a Google Meet add-on that loads an Angular web app inside the Meet side panel. The app initializes the Meet Add-on SDK, creates a session, gets meeting info, and then lets a bot connect via WebRTC to capture meeting audio streams.

This setup was working correctly before.

Architecture

• Angular frontend loaded in the Meet side panel

• Meet Add-on SDK (meet.addons.js)

• WebRTC connection to Meet Media API

• Cloud Run proxy exchanging SDP offer/answer

• Audio mixed with Web Audio API and recorded using MediaRecorder

What changed

I started experimenting with CoDoingClient from the Meet Add-on SDK. To support that, I added this field in the deployment config:

"supportsCollaboration": true

After adding that, the add-on stopped initializing in Meet.

I then:

• Removed "supportsCollaboration": true

• Reverted deployment.json to the previous working version

• Reverted the web app to the last known working revision

• Deleted the HTTP deployment

• Created a new deployment

• Republished it in the Workspace Marketplace store listing

Even this did not help, and the side panel still says that the add-on couldn't start (no logs in console). It is not published publicly but as an internal Workspace app.

Current problem

When launched inside Meet:

• My Angular logs never appear

But if I open the same sidePanelUrl directly in the browser, the app loads and works normally, and does show logs in the console.

Deployment config (current)

{
  "addOns": {
    "common": {
      "name": "Meet Add-on",
      "logoUrl": "..."
    },
    "meet": {
      "web": {
        "supportsScreenSharing": true,
        "addOnOrigins": ["https://my-cloud-run-url"],
        "sidePanelUrl": "https://my-cloud-run-url/some-path/meet-addon"
      }
    }
  }
}

Questions

1. Could enabling supportsCollaborationonce cause a persistent state/caching issue in Meet deployments?

2. Does Meet cache add-on deployments or manifests aggressively?

3. Is there a way to debug what happens before the add-on actually boots inside Meet?

Any insight from people who have worked with the Meet Add-on SDK would be really helpful.

Thanks,