How do I force stop a rogue Google Apps Script

by

Summary

A Google Apps Script continued running even after the user deleted the project, removed triggers, and emptied the trash. The script kept monitoring Gmail and sending Google Voice texts because an OAuth-granted authorization token was still active on the user’s Google Account. Deleting the script does not revoke its previously granted permissions, so the automation persisted.

Root Cause

The underlying issue was an active OAuth token tied to the user’s Google Account. Even though the script project was deleted:

  • The script had already been granted long‑lived permissions to access Gmail and Google Voice.
  • Google Apps Script can continue executing via headless triggers or queued executions if the authorization token remains valid.
  • Deleting the project does not automatically revoke OAuth grants.
  • The third‑party service likely created a standalone Apps Script deployment that no longer appeared in the user’s Apps Script dashboard.

Why This Happens in Real Systems

This pattern is common in distributed automation systems:

  • OAuth tokens outlive the application unless explicitly revoked.
  • Server-side clones of Apps Script projects can run independently of the user’s visible script list.
  • Triggers and executions may be owned by the script’s deployment, not the user’s editor environment.
  • Cloud automation platforms often create hidden or container-bound scripts that don’t show up in the user’s Apps Script IDE.

Real-World Impact

When OAuth tokens persist after deletion:

  • Rogue automations continue running without visibility.
  • Users lose control over email, messaging, or data access.
  • Unexpected actions (like sending texts) can cause:
    • Account lockouts
    • Rate-limit bans
    • Privacy or compliance issues
    • Confusing or embarrassing automated messages

Example or Code (if necessary and relevant)

Below is an example of how a script can continue running if its OAuth token remains active:

function autoReply() {
  const threads = GmailApp.search('is:unread');
  threads.forEach(t => {
    // Still runs as long as OAuth token is valid
    GmailApp.sendEmail("1234567890@txt.voice.google.com", "Auto reply", "I'm away");
  });
}

How Senior Engineers Fix It

Experienced engineers know that revoking OAuth tokens is the only reliable way to kill a rogue Apps Script.

They follow a systematic approach:

  • Revoke all third‑party access in Google Account → Security → Manage third‑party access.
  • Revoke Apps Script project tokens in Google Account → Security → Your devices & apps with account access.
  • Check Google Cloud Console for:
    • Hidden Apps Script projects
    • Service accounts
    • Deployed web apps
  • Remove any remaining triggers via:
    • script.google.com → My Triggers
    • Google Workspace Dashboard → Apps Script Activity
  • Force token invalidation by changing the Google Account password.
  • Audit OAuth grants using Google Account → Security → App passwords (if applicable).

The key fix is:
Revoke the OAuth grant, not the script.

Why Juniors Miss It

Less experienced engineers often assume:

  • Deleting the script stops execution.
  • Removing triggers is sufficient.
  • Apps Script projects always appear in the IDE.
  • OAuth permissions automatically expire.

They typically overlook:

  • Long-lived OAuth tokens
  • Server-side deployments
  • Hidden container-bound scripts
  • The difference between deleting code and revoking authorization

Senior engineers know that in cloud systems, authorization outlives artifacts, and the only real shutdown mechanism is revoking the token at the account level.

Leave a Comment