Forem: Caleb Hunter

I Use Google Drive as My Primary File System. Here's How I Got Claude Cowork to Play Nice With It.

Caleb Hunter — Thu, 02 Apr 2026 20:46:11 +0000

TL;DR: If you use Google Drive for Desktop in streaming mode, Claude Cowork can't reliably access those files. Set your working folders to "Available offline" (mirrored), grant Cowork access to those specific folders, and everything works. Details below.

I'm in the middle of going cloud-first with my file storage. The goal: use Google Drive as my primary document store, stream everything to my Mac via the Google Drive for Desktop app, and only mirror the folders I'm actively working in. Less local storage used, everything accessible from anywhere.

Then I started setting up Claude Cowork's file system access, and hit a question that I couldn't find a clear answer to anywhere.

The Setup

If you're not familiar with Google Drive for Desktop on macOS, here's the short version: it mounts your entire Google Drive as a volume in Finder. It looks and behaves like a normal folder full of normal files. You can navigate it, open files, drag things around. It feels local.

But it's not. By default, those files are streamed. They exist in the cloud. What you see in Finder are essentially placeholders that get downloaded on demand when you open them.

This matters when you introduce an AI tool that wants to read and write files on your machine.

The Question

Claude Cowork (the desktop app's automation feature) has a file system access permission. You grant it access to specific folders, and it can read, create, and modify files in those folders directly. No uploading, no copy-pasting. It just works with whatever is on disk.

So my question was straightforward: if I point Cowork at a folder that looks local but is actually my streamed Google Drive, what happens? Can it read those files? Will it error out? Will it silently fail?

This is different from Claude's Google Drive connector in chat, which works with cloud-native Google Docs and Sheets directly. Cowork's file system access is a different mechanism entirely. It sees files on disk, period.

What I Found

The core issue comes down to one distinction: streaming vs. mirroring.

Google Drive for Desktop has two modes for how it handles your files:

Streaming is the default. Files live in the cloud. Finder shows them, but the actual bytes only get pulled down when you (or an app) opens them. Until that happens, the file is basically a stub. It has a name and an icon, but there's nothing really there yet from a filesystem perspective.

Mirroring means the files live both in the cloud and fully on your local disk. The bytes are always present. Changes sync both directions automatically.

Cowork runs in an isolated environment and interacts with files through the folders you share with it. When it tries to open a file, it needs actual bytes on disk. A streamed placeholder that hasn't been downloaded yet? Cowork may not see it at all, or it may throw an error.

So the answer to my question: streamed-only files are unreliable with Cowork. Mirrored files work perfectly.

The File Format Gotcha

There's a second thing worth knowing.

In Claude chat with the Google Drive connector, you can work directly with native Google Docs, Sheets, and Slides. Those are cloud-native formats that the connector understands.

Cowork's file system access is different. It works with actual files: .docx, .txt, .md, .xlsx, .pdf, code files, and so on. If you have a Google Doc in your Drive, it shows up in Finder as a .gdoc shortcut that opens in your browser. Cowork can't edit that. It's not a real document file.

If you want Cowork to work with a Google Doc through the filesystem, you need that document saved or exported as a standard format like .docx or .md. Then it's a real file, and Cowork handles it like any other.

My Setup (What Actually Works)

Here's the configuration I landed on:

Keep streaming as the global default. The whole point of my cloud-first approach is to save local disk space. I don't need years of archived documents taking up room on my laptop.

Selectively mirror the folders I'm actively working in. In Finder, I right-click the specific Drive folders I want Cowork to access and choose "Make available offline." Google Drive downloads those folders and keeps them synced locally. Everything else stays streamed.

Grant Cowork access only to those mirrored folders. In the Claude desktop app's file system settings, I point it at the mirrored project folders. Not my entire Drive. Not my whole disk. Just the working directories.

Use local-friendly file formats for anything I want Cowork to touch. That means .md, .txt, .docx, .xlsx, and standard code files. If I need to work with a Google Doc through Cowork, I export it first.

The result: Cowork treats those mirrored Drive folders like normal local directories. It reads and writes files without issues. Google Drive syncs changes back to the cloud automatically. I get the cloud-first storage I wanted with the local AI tooling I need.

Quick Reference: Claude Chat vs. Cowork for Google Drive Files

	Claude Chat + Drive Connector	Cowork + File System Access
What it accesses	Cloud-native Google Docs/Sheets/Slides	Real files on disk (.docx, .md, .txt, etc.)
Where files live	Google Drive (cloud)	Your local filesystem (shared folders)
Google Docs support	Native, works directly	Needs export to .docx or similar
Best for	Quick document Q&A, cloud-native editing	Sustained file work, batch operations, code
Requires	Google Drive connector enabled	File system access + mirrored folders

What I'd Do Differently

If I were setting this up from scratch, I'd create a dedicated Claude-Projects folder in Google Drive on day one and set it to mirror immediately. All active working files go there. When a project wraps, I move the folder back to stream-only to reclaim the disk space. That way the boundary between "Cowork can touch this" and "this is just cloud storage" is always clear, and I'm not retroactively figuring out which folders need to be mirrored.

The Takeaway

If you're using Google Drive for Desktop and want to work with Claude Cowork's file system access, the key thing to know is that "looks local" and "is local" are not the same thing. Streamed files are placeholders until they're actually downloaded, and Cowork needs real bytes on disk.

The fix is simple: mirror the specific folders you need, point Cowork at those folders, use standard file formats, and let Drive handle the cloud sync in the background.

It's a small configuration detail, but it's the kind of thing that can waste an afternoon if you don't know to look for it.

I work in developer relations and community building, and I'm a builder exploring how AI tools fit into real daily workflows. You can find more of what I'm working on at calebhunter.dev. If you're experimenting with Claude Cowork, Claude Code, or similar tools, I'd like to hear how you're setting up your environment. What's working? What tripped you up?

Resurrecting the 1990s Web: Building a VRML Parser in 9 Days with Kiro

Caleb Hunter — Fri, 05 Dec 2025 21:10:05 +0000

How AI-assisted development and 20 years of VR expertise brought dead 3D web standards back to life

The Problem: Digital Archaeology

While cleaning out some old university archives recently, I stumbled upon something fascinating: thousands of .wrl files from the 1990s—virtual art galleries, 3D molecular models, early game prototypes—all completely inaccessible in modern browsers.

VRML (Virtual Reality Modeling Language) was the web's first attempt at 3D content, predating WebGL by over a decade. It died spectacularly when browser plugins fell out of favor, leaving an entire generation of 3D creativity frozen in digital amber.

As someone who spent 20+ years in VR/AR at Meta, I couldn't let that stand. But there was one problem: I'd been in program management for years, not writing production code.

Enter Kiro.

Why VRML is Terrifyingly Complex

VRML isn't just "old"—it's aggressively 1990s. The syntax has quirks that would make a modern parser cry:

# Yes, comments start with # like Python
Transform {
  translation 0.5 1.0 0.5  # NOT a JSON array!
  rotation 0 1 0 1.5708    # Axis-angle, NOT Euler angles
  children [
    Shape {
      appearance Appearance {
        material Material {
          transparency 0.5  # 0=opaque (INVERTED from CSS!)
        }
      }
      geometry Box { size 1 1 1 }  # Optional commas everywhere
    }
  ]
}

Modern parsers assume JSON-like syntax. VRML assumes you're writing in 1997 and have all the time in the world.

The Kiro Advantage: Teaching an AI About the Past

Here's where things got interesting. Instead of fighting with Kiro to understand VRML, I taught it using steering documents.

I created .kiro/steering/project-context.md with critical context:

## VRML Syntax Quirks
- Uses SFVec3f notation: `0.5 1.0 0.5` (NOT JSON arrays)
- Rotations in axis-angle format (x, y, z, angle)
- Transparency is 0=opaque, 1=fully transparent (INVERTED from CSS)

That last line? Saved me 6 hours of debugging.

Without steering, every conversation about transparency started with Kiro generating CSS-style opacity code (0=transparent). With steering, it immediately understood VRML's inverted semantics.

Small investment. Massive ROI.

Spec-Driven Development for Complex Parsers

For the core parser logic, I used spec-driven development—writing detailed specifications before any code.

.kiro/specs/vrml-parser.md broke VRML into digestible chunks:

Phase 1: Lexer (tokenization, comments)
Phase 2: Basic nodes (shapes, materials, transforms)
Phase 3: Advanced geometry (IndexedFaceSet meshes)
Phase 4: Materials & effects (transparency, emissive colors)

The IndexedFaceSet parser was the test case. These nodes define real 3D meshes using flat coordinate arrays with -1 separators:

geometry IndexedFaceSet {
  coord Coordinate {
    point [ 0 0 0, 1 0 0, 1 1 0, 0 1 0 ]
  }
  coordIndex [ 0, 1, 2, -1, 0, 2, 3, -1 ]  # -1 = face boundary
}

Converting this to Three.js BufferGeometry while calculating face normals? That's a ~150-line function that needs to work perfectly.

With vibe coding alone: 3-4 debugging iterations

With spec-driven development: Worked on first try

The Hybrid Approach: When to Spec, When to Vibe

Nine days in, I learned which tool fit which job:

Specs won for:

Complex data structures with edge cases
Parser logic (deterministic rules)
Anything that needed to work perfectly first time

Vibe coding won for:

UI components (subjective design)
Quick bug fixes ("the rotations are inverted, flip the sign")
Creative content (the Halloween graveyard demo scene)

The key insight: Use both strategically. Don't force specs on subjective design. Don't iterate through vibe coding on complex logic.

Agent Hooks: The Secret Weapon

The real productivity unlock? Agent hooks.

I created .kiro/hooks/test-scene.sh that automated:

VRML syntax validation
Parser execution on all test files
A-Frame output generation
Auto-opening results in browser

Before hooks: 3-minute iteration cycle

After hooks: 15-second iteration cycle

Over 9 days, this saved ~10 hours of manual testing. That's 10 hours I spent adding features instead of clicking buttons.

The deployment hook was even better—it caught that I'd accidentally added .kiro to .gitignore, which would've been instant disqualification from the hackathon.

Hooks literally saved my submission.

The VR Background Advantage

Here's the thing most developers won't tell you about AI-assisted development: domain expertise is the multiplier.

My 20 years in VR meant I could describe problems precisely:

❌ "The 3D models aren't rendering right"

✅ "IndexedFaceSet coordinate arrays with -1 face separators need conversion to Three.js BufferGeometry with proper normal calculation"

That specificity eliminated trial-and-error iterations. Kiro isn't replacing expertise—it's amplifying it.

Most Kiroween participants are full-stack web developers. I'm the only one with serious spatial computing experience. That differentiation matters when judges evaluate 3,000+ submissions.

What I'd Do Differently

I should have used MCP. I explored Model Context Protocol for 3D validation but didn't implement due to time constraints. In retrospect, integrating external VRML validation tools would've caught edge cases earlier.

I should have recorded more. Kiro's most impressive moments (generating the IndexedFaceSet converter perfectly on first try) weren't screenshotted. Document everything—you'll want it for writeups.

I should have started the demo scene earlier. The Halloween graveyard with 35 glowing jack-o'-lanterns and transparent ghosts was built on day 8. Starting earlier would've given more iteration time.

The Result: Production-Grade in 9 Days

VRML Reborn now parses:

8 major node types (Shape, Transform, Material, etc.)
Complex IndexedFaceSet meshes (real 3D geometry)
Advanced materials (transparency, emissive colors)
Nested transforms and DEF/USE references
WebXR with one-click VR mode

Try it: [your-vercel-url-here]

Upload any .wrl file and watch a piece of 1990s web history come back to life.

The Real Lesson: AI + Expertise = Magic

Kiro didn't write this project. I didn't write this project. We built it together.

The combination of:

Steering docs (teaching Kiro about 1990s quirks)
Specs (handling complex logic deterministically)
Vibe coding (rapid UI iteration)
Hooks (automation that saved hours)
Domain expertise (20 years of spatial computing)

...created something neither of us could have built alone.

That's the future of development: not AI replacing developers, but AI amplifying what makes each developer unique.

Now if you'll excuse me, I have 500 more vintage VRML files to resurrect.

Burning the Midnight Oil to Bring Back VR from the 90s

Caleb Hunter — Fri, 05 Dec 2025 03:51:07 +0000

10:30 PM and I'm this close to bringing 1997's VRML back from the dead 🎃👻

Parser finally rendering glowing jack-o'-lanterns and transparent ghosts.
The graveyard is coming alive for @kirodotdev's #Kiroween 🔥

Tomorrow: demo video, then ship it.

Update on my Kiroween project 🎃

Caleb Hunter — Wed, 03 Dec 2025 17:10:17 +0000

Started with a parser that only showed default cubes. Now rendering actual 3D meshes from 90s VRML files!

The breakthrough: Adding IndexedFaceSet support to parse vertices and face indices into THREE.js BufferGeometry.

Kiro helped me:

Debug the nested brace matching issue
Build custom A-Frame geometry components
Fix React re-render conflicts with A-Frame registration

From "everything is a teal cube" → actual colored 3D shapes ✨

@kirodotdev

Debugging with Kiro is a Breeze

Caleb Hunter — Wed, 03 Dec 2025 16:12:46 +0000

Just had an "aha" moment debugging with @kirodotdev 🎃

Building a VRML → WebXR converter for #Kiroween and hit a wall — my parser was showing a default cube for every file.

Kiro helped me:

Add console logging to trace the issue
Identified the regex wasn't handling nested braces
Fixed it in under 5 minutes

Before: 🟦 (same teal cube for everything)
After: 🔴🌍 (actual red spheres and 3D globes!)

The conversational debugging flow is a game-changer. Instead of Stack Overflow rabbit holes, I just described the problem and Kiro walked me through it.