How to Fix Gmail Unavailable in Codex

Watch the live training this article came from

Back to the Goal Mode framework

When Codex tells you Gmail is unavailable, most business owners do one of two things: they try to reconnect the plugin, or they stop and assume something is broken. Both responses miss the actual problem by a full day.

The error isn't happening on Day 3. It originated on Day 1.

That's the diagnosis most people never hear, and it's the reason they spend hours troubleshooting the wrong layer. There's no patch for this at the plugin level. The fix lives in the foundation, in the machine-level permissions that were either completed correctly during initial setup or weren't. There's no third option.

Watch me explain this live if you want to see the troubleshooting conversation in real time.

The Root Cause Most People Skip Past

Here is the upgraded framing I use when I walk business owners through this:

When Codex tells you Gmail is unavailable, it isn't broken. You are. Specifically: something from Day 1 was skipped, rushed, or incomplete. That's the only explanation. It's a Day 1 problem presenting as a Day 3 problem. No troubleshooting ticket fixes it. You go back to the foundation and complete what was skipped.

This is not a criticism. Day 1 permissions setup is genuinely unglamorous. There's nothing exciting about granting machine-level access to file systems, browsers, and communication tools. It doesn't feel like building an AI business. It feels like IT setup. So people rush it, skip steps, or partially complete it and assume it was good enough.

It is almost never good enough if something is "unavailable" on Day 3.

The entire goal mode architecture, every automated email, every social post, every tool Codex touches, is downstream of those initial permissions. Miss one step and a specific tool goes dark. Miss several and the whole system limps. The frustrating part is that the failure doesn't show up immediately. It shows up on Day 3, when you're trying to run a real goal, which is the worst possible time to discover a Day 1 error.

What "Unavailable" Actually Means

When a plugin shows as unavailable, Codex is not experiencing a temporary glitch. It's encountering a permission wall that was never removed during setup. The tool exists. The connection path exists. The authorization that would allow traversal of that path does not.

Here's what this looks like across the most common tools:

The Windows case is worth noting specifically: if plugins are greyed out on a Windows machine, right-clicking the Codex application and selecting "Run as Administrator" often resolves it. This is the Windows equivalent of the same Day 1 permissions issue, administrative access wasn't granted to the application.

The Fix: Don't Ask. Command.

Here's where most business owners make a second mistake on top of the first. They ask Codex politely whether it can try again. They accept "unavailable" as a final state. They assume there's nothing to be done.

There's plenty to be done. But you have to push back directly.

The exact language that works:

"Open the browser and tell me where to click. Take control, use computer use, use browser use. Do this for me now."

That's it. That is the command. Not a question. Not a request. A direct instruction that hands the navigation task to Codex instead of asking you to figure it out yourself.

Codex has computer use capability, it can operate a browser on your behalf, navigate to the correct authorization screen, and walk you through exactly where to click. It will not do this automatically if you accept "unavailable" as the answer. You have to require it.

I walked my mother through exactly this. She was using an OpenClaw personal assistant agent and kept hitting the same wall, the agent would report that things were unavailable, or it would ask her for help instead of acting. The correction wasn't technical. I coached her to be forceful. To tell it: open the browser, tell me where to click, take control. The problem resolved. Not because the permissions magically appeared, but because she stopped treating "unavailable" as a dead end and treated it as an instruction gap instead.

Do not accept "unavailable" as a final answer. It is never a final answer. It is a prompt for a more direct command.

Handling a Second Gmail Account (OAuth)

A specific version of this problem comes up frequently when business owners need Codex to access two Gmail accounts, for example, one personal account and one business account, or two separate business email addresses.

The second account will not be recognized automatically. It requires its own OAuth authorization, separate from the first.

The process:

1. Authorize a new OAuth connection specifically for the second Gmail account
2. Store the credentials in your agent home base, the structured folder system where Codex retrieves business context and access information across threads
3. Verify Codex can locate and reference the credentials before activating any goal that requires that account

The agent home base step matters more than most people realize. Without it, Codex treats every new conversation thread as a blank slate. Even if you successfully authorized the second OAuth connection, Codex has no persistent memory of that authorization unless the credential is stored somewhere it can retrieve. If the credential lives only in one thread's context, it disappears when that thread closes.

This is not a bug. It's an architecture gap. The fix is structural: build the home base, store the credentials there, and let Codex pull from it instead of relying on thread memory.

For more on how the home base functions as the memory layer across sessions, read the full framework guide.

The Prevention Checklist

The most efficient path through this problem is not fixing it, it's not creating it in the first place. Here is what complete Day 1 permissions setup looks like for the tools that commonly show as unavailable:

Before activating any Codex goal, verify:

• Machine-level permissions have been granted (file system access, browser access, communication tools)
• Gmail account(s) are fully authorized, not just connected, but given the correct permission scope
• If running a second Gmail account, OAuth is authorized separately and credentials are stored in the agent home base
• On Windows: Codex is running as Administrator
• Browser-based tools (Facebook, Instagram, etc.) have an active logged-in session visible in the browser Codex uses
• Codex app is updated, the blue update indicator in the top-left of the app means a new version is available; click "Check for Updates"

Run this checklist before your first goal. Run it again if anything reports as unavailable. Most issues resolve at step one or two.

Why This Is Step 15, Not Step 1

There's a reason I'm writing about troubleshooting here rather than at the beginning of this series. The errors business owners hit on Day 3 are visible on Day 3. The causes were set on Day 1. Most people won't feel the urgency of complete permissions setup until they're trying to run a real goal and something is blocking them.

Now you know the reverse: every tool you want Codex to use during a goal must be authorized before you need it. The goal setup is not the moment to discover that Gmail requires permissions you never granted. That discovery should happen during setup, on a day when nothing is running and nothing is at stake.

Day 1 is not setup. It is the strategy. The goal is just the execution.

For the complete framework on how setup determines every downstream result, including goal design, access configuration, and parameter structure, read the full guide.

Common Mistakes on This Step

Accepting the first error message as final. "Unavailable" is not a state. It's a gap in permissions. Push back with a direct command every time.

Reconnecting the plugin instead of checking the permission. Disconnecting and reconnecting a plugin does not resolve a permissions issue at the machine level. You're moving furniture when the problem is the foundation.

Assuming Day 1 is complete because Day 2 worked. Some permissions issues only surface when specific tools are called. Gmail may not be needed until a goal requires it. Absence of errors on Day 2 is not confirmation that Day 1 is complete.

Storing OAuth credentials only in a single thread. Cross-thread credential access requires the agent home base. If the credential isn't stored there, Codex can't find it in the next session.

Running Codex without Administrator permissions on Windows. Greyed-out plugins on Windows have one fix: right-click, Run as Administrator. Try this before anything else on a Windows machine.

Plugin connectivity errors are the most demoralizing part of getting started with goal mode. They feel like the system is broken. They feel technical and unsolvable. They're neither. They are a single skipped step in a Day 1 checklist, dressed up as a Day 3 crisis.

Go back to the foundation. Complete the step. The goal will run., Shanee

Back to the Goal Mode framework