


Hi,
You've already ruled out everything on the code/config side (empty script, Default GCP project, no Advanced Protection, same browser/device/network works for another account). That checklist is solid evidence this isn't an app problem — it's an account-level restriction on Google's side, not something in your script.
What's likely happening:
Google runs risk-based checks on OAuth consent grants, separate from the app itself. A few things commonly trigger it on one account while a sibling account stays clean:
This is usually temporary (anywhere from a day to ~2 weeks) and self-resolves — there's no manual "unblock Apps Script" switch for a consumer account, since the block isn't tied to the script at all.
Things worth trying, in order:
To answer your specific questions: yes, this is very likely a temporary risk-based restriction rather than a permanent flag, and no, there isn't a self-service reset for Apps Script OAuth specifically — it follows the same account trust signals as any other OAuth consent.
Hope that saves you some debugging time.
## Apps Script OAuth authorization blocked for only one Google account
Hello,
Based on the tests described, this does not appear to be a problem with the script, browser, computer, network, spreadsheet, or Google Cloud project.
The most important evidence is that another Google account can authorize and execute the same Apps Script project under the same conditions.
That strongly suggests that the authorization failure is related specifically to the affected Google account.
---
## Important distinction between OAuth messages
There are two different authorization messages that are often confused:
### “This app isn’t verified”
This message usually appears when an OAuth application requests sensitive or restricted scopes but has not completed Google’s verification process.
In many cases, the user can select:
**Advanced → Go to the application**
This is generally a warning rather than a complete block.
### “This app is blocked”
This message is more serious.
It indicates that Google has prevented the authorization request entirely. Normally, there is no option to continue.
For a new Apps Script project created and executed by the same user, especially one that only uses a standard service such as `SpreadsheetApp`, this message is not expected.
---
## Why OAuth verification is probably not the issue
The following test code uses a built-in Apps Script service:
```javascript
function test() {
SpreadsheetApp.getActiveSpreadsheet();
}
```
Apps Script automatically determines the OAuth scopes required by the code.
For a script created and executed by its own owner, Google OAuth verification is normally not required just to run the script.
OAuth verification becomes more relevant when:
* A script is distributed to many external users.
* A web application executes as the accessing user.
* An add-on is published.
* Sensitive or restricted OAuth scopes are requested.
* The application uses a custom Google Cloud project and OAuth consent screen.
Since this is a brand-new script using the default Apps Script Cloud project, the issue is unlikely to be caused by an unverified custom OAuth application.
---
## Most likely causes
### 1. Google Workspace administrator restriction
First, confirm whether the affected account is:
* A Google Workspace business account.
* A school or university account.
* An organization-managed account.
* A managed family or supervised account.
A Google Workspace administrator can restrict OAuth applications and prevent users from authorizing applications that request certain scopes.
The administrator should check:
**Admin Console → Security → Access and data control → API controls → App access control**
The administrator should verify:
* Whether Google Apps Script is enabled for the user.
* Whether the user belongs to a restricted organizational unit.
* Whether OAuth app access controls are blocking the request.
* Whether Google Workspace services such as Drive and Sheets are enabled.
* Whether the Apps Script application is classified as blocked or limited.
* Whether third-party application access is restricted.
Even though Apps Script is a Google service, authorization policies can still affect the scopes requested by a script.
---
### 2. Age, supervision, or account eligibility restrictions
Some Google accounts may have additional restrictions because of:
* Family Link supervision.
* Age-related account settings.
* School account policies.
* Organization-specific security policies.
* Regional account requirements.
These restrictions may prevent the account from granting OAuth access, even when another account works normally.
The fact that Advanced Protection is disabled does not exclude other account-level restrictions.
---
### 3. Corrupted or inconsistent authorization state
The account may have an inconsistent authorization state for Apps Script.
This can happen when:
* An authorization was previously revoked.
* A project was deleted or recreated.
* OAuth permissions were changed.
* A script switched between Cloud projects.
* An authorization request was interrupted.
* A previous token became invalid.
The user should review the account’s connected applications:
**Google Account → Security → Your connections to third-party apps and services**
Remove any entries related to:
* Google Apps Script.
* The affected project.
* Old test projects.
* OAuth test applications.
After removing the access, reopen the Apps Script project and try again.
---
## Invalidating the Apps Script authorization
Apps Script provides a method to invalidate the current project authorization.
Add and run the following function:
```javascript
function resetAuthorization() {
// Invalidates the current user's authorization for this script.
ScriptApp.invalidateAuth();
console.log('Authorization invalidated.');
}
```
After running it:
1. Close the Apps Script editor.
2. Sign out of the affected Google account.
3. Sign in again.
4. Open the project.
5. Run the test function again.
Important: `ScriptApp.invalidateAuth()` only invalidates the authorization associated with the current script.
It cannot remove an account-level restriction applied by Google or by a Google Workspace administrator.
---
## Check the Apps Script manifest
Open the project settings:
**Project Settings → Show “appsscript.json” manifest file in editor**
Review the `appsscript.json` file.
For a basic test project, it should look similar to this:
```json
{
"timeZone": "Asia/Bangkok",
"dependencies": {},
"exceptionLogging": "STACKDRIVER",
"runtimeVersion": "V8"
}
```
Pay special attention to the `oauthScopes` property.
For example:
```json
{
"timeZone": "Asia/Bangkok",
"oauthScopes": [
"https://www.googleapis.com/auth/spreadsheets",
"https://www.googleapis.com/auth/drive"
],
"exceptionLogging": "STACKDRIVER",
"runtimeVersion": "V8"
}
```
If `oauthScopes` was added manually, temporarily remove it.
Apps Script can automatically detect the scopes required by the code.
Manually defined scopes can accidentally request broader permissions than necessary.
After removing `oauthScopes`:
1. Save the manifest.
2. Refresh the editor.
3. Run the test again.
---
## Use a better isolated test
The original code uses:
```javascript
SpreadsheetApp.getActiveSpreadsheet();
```
In a standalone Apps Script project, there may not be an active spreadsheet.
That would normally return `null` rather than produce an OAuth block, but it is better to use a clearer test.
Create a completely new standalone project and use:
```javascript
function testSpreadsheetAuthorization() {
// Creates a new spreadsheet to test the Sheets authorization scope.
const spreadsheet = SpreadsheetApp.create(
`OAuth Test ${new Date().toISOString()}`
);
console.log(`Spreadsheet created: ${spreadsheet.getUrl()}`);
}
```
This function performs a real operation that requires authorization.
If the authorization window is immediately blocked before execution, the problem is clearly related to OAuth rather than the active spreadsheet context.
---
## Test a service with a smaller authorization requirement
You can also test whether the account can execute a function that does not require access to Sheets or Drive:
```javascript
function testBasicExecution() {
const result = {
timestamp: new Date().toISOString(),
timeZone: Session.getScriptTimeZone(),
temporaryUserKey: Session.getTemporaryActiveUserKey()
};
console.log(JSON.stringify(result, null, 2));
}
```
If this function runs but the spreadsheet test is blocked, the restriction may be related specifically to Drive or Sheets scopes.
If even basic execution triggers the blocked authorization message, the problem may affect Apps Script authorization more generally.
---
## Test the account in the Apps Script dashboard
Open the Apps Script dashboard with the affected account.
Check whether:
* Existing projects are listed.
* New projects can be created.
* Executions appear in the execution history.
* Any warning banners are displayed.
* The account can open project settings.
* Projects created by other users can be opened.
Also test a script bound directly to a spreadsheet:
1. Create a new Google Sheet.
2. Open **Extensions → Apps Script**.
3. Add:
```javascript
function testBoundScript() {
const spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
console.log({
spreadsheetId: spreadsheet.getId(),
spreadsheetName: spreadsheet.getName()
});
}
```
4. Run the function.
This distinguishes a standalone project problem from a broader Apps Script authorization issue.
---
## Check third-party cookies and browser account sessions
Although another account works in the same browser, it is still worth testing the affected account with a clean session.
Recommended test:
1. Sign out of all Google accounts.
2. Open a new Chrome Guest window.
3. Sign in only with the affected account.
4. Open the Apps Script project.
5. Run the test.
This avoids account-selection conflicts during OAuth.
Also verify that third-party cookies are not being blocked for Google authorization domains.
However, because the message is “This app is blocked,” rather than a blank popup or redirect error, browser settings are less likely to be the root cause.
---
## Check whether the account is using a managed Chrome profile
Even when the Google account itself is personal, the Chrome profile or device may be managed.
Open:
```text
chrome://management
```
Also check:
```text
chrome://policy
```
Look for policies related to:
* OAuth.
* Google sign-in.
* Third-party cookies.
* URL blocking.
* Extension restrictions.
* Account restrictions.
This is less likely because another account works in the same Chrome profile, but it is still useful to eliminate device-management policies.
---
## Should a custom Google Cloud project be created?
Creating a custom Google Cloud project should not be the first solution.
A standard Apps Script project using the default Cloud project should be able to authorize normally.
Creating a custom project would add:
* OAuth consent screen configuration.
* OAuth scope configuration.
* Test-user configuration.
* API enablement requirements.
* Additional opportunities for configuration errors.
It may also hide the original account-level problem rather than solve it.
A custom Cloud project is only useful as a diagnostic test after the simpler checks have been completed.
---
## Could this be a temporary risk-based restriction?
Yes, it is possible.
Google uses automated security systems to evaluate account activity and authorization requests.
A temporary restriction could theoretically be triggered by:
* Multiple authorization attempts.
* Rapid creation of many scripts.
* Repeated OAuth consent requests.
* Unusual login activity.
* Frequent IP address changes.
* VPN or proxy usage.
* Recent account recovery.
* Password or security-setting changes.
* Automated activity detected on the account.
However, Google does not publicly document every condition that can trigger account-level OAuth restrictions.
Therefore, it is not possible to confirm from the error message alone that this is a temporary risk-based restriction.
If it is temporary, it may clear automatically after the account’s security state is reviewed. However, repeatedly attempting authorization many times may not help.
---
## Is there a way to reset Apps Script OAuth for the account?
There is no documented user-facing button specifically named “Reset Apps Script OAuth authorization.”
The available user actions are:
* Remove existing application access from the Google Account security page.
* Use `ScriptApp.invalidateAuth()`.
* Remove explicit OAuth scopes from the manifest.
* Create a fresh Apps Script project.
* Test in a clean browser session.
* Review account security settings.
* Ask the Google Workspace administrator to review API controls.
* Contact Google support.
If the restriction exists at the Google account security-system level, it cannot be removed through Apps Script code.
---
## When to contact Google support
Contact support when all the following are true:
* A completely new Apps Script project is blocked.
* The default Cloud project is being used.
* No custom OAuth client exists.
* No explicit OAuth scopes are configured.
* Another account works under identical conditions.
* The affected account is not using Advanced Protection.
* There are no visible account security alerts.
* The problem persists in a clean browser session.
* Both standalone and spreadsheet-bound scripts are affected.
For a Google Workspace account, the Workspace administrator should open the support case.
For a personal Google account, use the available Google Account support channels and report the issue in the Apps Script community or issue tracker when appropriate.
---
## Information to include in the support request
Provide:
* Type of account: personal Gmail or Google Workspace.
* Whether the account is supervised.
* Approximate date and time of the failure.
* Time zone.
* Full error message.
* Screenshot with personal information removed.
* Apps Script project ID.
* Whether the project is standalone or container-bound.
* Whether the default Cloud project is used.
* The exact minimal test code.
* The OAuth scopes shown in the project overview.
* Confirmation that another account works.
* Confirmation that the test was performed in a clean browser session.
* Browser version.
* Operating system.
* Whether a VPN or proxy is used.
Do not publicly post:
* OAuth access tokens.
* Refresh tokens.
* Client secrets.
* Session cookies.
* Account recovery information.
* Full security logs.
* Private spreadsheet URLs.
---
## Suggested minimal reproduction
```javascript
/**
* Minimal OAuth authorization test for Google Sheets.
*
* Expected behavior:
* The user should be asked to authorize the script.
* After authorization, a new spreadsheet should be created.
*/
function testSpreadsheetOAuth() {
const fileName = `Apps Script OAuth Test - ${new Date().toISOString()}`;
const spreadsheet = SpreadsheetApp.create(fileName);
console.log({
id: spreadsheet.getId(),
name: spreadsheet.getName(),
url: spreadsheet.getUrl()
});
}
```
Recommended manifest:
```json
{
"timeZone": "Asia/Bangkok",
"dependencies": {},
"exceptionLogging": "STACKDRIVER",
"runtimeVersion": "V8"
}
```
---
## Final assessment
Based on the evidence, the most probable causes are:
1. An account-level Google Workspace, supervision, or age policy.
2. A corrupted authorization state associated with the account.
3. A temporary or automated security restriction.
4. An explicit or unexpected OAuth scope in the project manifest.
5. A Google-side account authorization issue.
The script itself is unlikely to be the cause.
The fact that another Google account successfully authorizes the same script in the same environment is the strongest indication that the problem belongs to the affected account’s authorization or policy state.
If all local authorization cleanup and administrator checks fail, the issue likely requires investigation by Google support because Apps Script does not provide a method to override or reset an account-level OAuth security block.