cd /news/developer-tools/i-drive-a-cloud-coding-agent-from-my… · home topics developer-tools article
[ARTICLE · art-75581] src=ykdojo.github.io ↗ pub= topic=developer-tools verified=true sentiment=· neutral

I drive a cloud coding agent from my phone through the browser

A developer configured Google Cloud's Identity-Aware Proxy (IAP) in front of a Cloud Run service running a coding agent in a web terminal, enabling access from a phone browser via Google sign-in. The setup solves the autoscaling issue where Tailscale bypassed Cloud Run's front end, causing idle timeouts, while IAP keeps the instance alive during active WebSocket connections. The approach works for any CLI coding agent and requires three gcloud commands plus a custom OAuth client for personal projects without an organization.

read4 min views1 publishedJul 27, 2026

tl;dr: I put Google’s Identity-Aware Proxy in front of a Cloud Run service running a coding agent in a web terminal. Now I open a URL on my phone, sign in with my Google account, and I’m talking to the agent.

Source: github.com/ykdojo/antigravity-cloud-run

This builds on my containerized dev environments setup: the agent runs with --dangerously-skip-permissions

inside a container on Cloud Run, reachable through a web terminal. The missing piece was using it away from my laptop.

This particular setup was done for Antigravity CLI, but it should work for pretty much any other CLI coding agent.

My sessions already join my Tailscale network, so the obvious route was the Tailscale app on the phone. It works, but there’s a catch: tailnet traffic bypasses Cloud Run’s front end entirely, so the autoscaler thinks the service is idle and reclaims the instance after about 15 minutes, mid-use. The only fix is pinning the instance with min-instances=1, which costs money around the clock whether I’m using it or not.

IAP flips that. Identity-Aware Proxy is Google Cloud’s managed sign-in gate: you put it in front of a service, and only the Google accounts you allowlist get through. You open the service’s regular run.app

URL, sign in, and you’re at the terminal. The terminal’s WebSocket is a real ingress request, so opening the tab wakes the instance, keeps it alive while you’re connected, and lets it scale back to zero when you close the tab.

If you want the instance to never die, deploy with min-instances=1 and it never scales down to zero.

Enabling IAP on the service itself is three commands:

gcloud run services update SERVICE --region REGION --iap

gcloud run services add-iam-policy-binding SERVICE --region REGION \
  --member serviceAccount:service-PROJECT_NUMBER@gcp-sa-iap.iam.gserviceaccount.com \
  --role roles/run.invoker

gcloud beta iap web add-iam-policy-binding --resource-type=cloud-run \
  --service SERVICE --region REGION \
  --member user:YOU@gmail.com --role roles/iap.httpsResourceAccessor

If your project lives in a Google Cloud organization, you may be done. Mine doesn’t, so I needed to take a long detour. In case you need to go through the same thing, here is what I went through.

After enabling IAP, every request returned a 502 with this body:

Empty Google Account OAuth client ID(s)/secret(s).

The reason: IAP’s Google-managed OAuth client only authenticates users inside your organization. A personal project has no organization, so there is no client at all, which is why it says “empty”. External users need a custom OAuth client handed to IAP. Four steps, mostly console clicks:

Branding (console, Google Auth Platform → Overview → Get started): app name, support email, audience External, agree to the API user-data policy.

https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect

. Note that Google now shows the secret only at creation time, so grab it then.Hand the client to IAP, at the project level so every IAP service in the project inherits it:

access_settings:
  oauth_settings:
    client_id: CLIENT_ID
    client_secret: CLIENT_SECRET
gcloud iap settings set iap_settings.yaml --project PROJECT

Delete the yaml afterwards. IAP stores the secret as a hash.

The change takes effect in seconds: the 502 is gone, and the service URL redirects to a Google sign-in instead. On the phone: open the service URL, pick your Google account, and the terminal loads.

One thing stops working: gcloud run services proxy

, which is how my dashboard embeds cloud terminals locally on my laptop. IAP rejects the proxy’s tokens, and on a no-organization project there’s no clean way around it.

So it’s a per-session choice, and I made it a flag: my deploy script takes -i

to bring a session up with IAP, and the dashboard shows those sessions as an “open in browser” link instead of an embedded terminal. Default is no IAP.

Here’s a phone

session with IAP next to a laptop

session without it. The IAP one opens in a browser tab; the other one connects through the local proxy and gets embedded in the dashboard:

It’s a checkbox when creating a session too, off by default:

The basic functionality works: I can open a session from my phone, type a task, and watch it run. A couple of rough edges I’m hoping to address later.

Scrolling isn’t great. It’s a terminal in a browser tab, so scrolling back through output on a touchscreen is fiddlier than it should be.

Font size is the other one. I can’t get it to set properly on the phone. It works in every other browser I tried, so I’m not sure what’s different there yet.

── more in #developer-tools 4 stories · sorted by recency
── more on @google cloud 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-drive-a-cloud-codi…] indexed:0 read:4min 2026-07-27 ·