Step 11: Verify Plugin Access With Proof

If you connected your plugins, got the green checkmark, and moved on — you skipped the most important step.

I see this constantly with business owners setting up Codex for the first time. They click through the plugin connection flow, see the confirmation screen, and assume the work is done. It isn't. Connecting a plugin and actually having functional access to your data are two different things. Treating them as the same thing is how you end up building on a blind spot.

This post covers exactly one step: how to verify that your plugins actually work after you connect them. Not the connection process itself — that's covered in the install and connect guide. This is the step that comes after, and most people skip it entirely.

For the complete framework covering every layer of Codex setup, read the full guide. And if you want to see this verification step done live on a real business, watch me explain this live.

Why Plugin Verification Is a Separate Step

When you authorize a plugin — Gmail, Google Drive, Google Calendar, Stripe — Codex returns a confirmation. The handshake completed. The integration exists. And that is the extent of what the confirmation tells you.

It does not tell you the depth of access. It does not confirm that Codex can actually retrieve the specific data you need. Some plugins are shallow integrations. They connect at the surface level but return limited data, stall on complex queries, or produce results that don't match your actual records.

The danger is not that the plugin fails visibly. The danger is that it appears to work. You ask Codex a business question later — something that depends on your email history or your sales data — and it produces an answer that sounds plausible. If you've never verified that Codex can actually pull real data from that source, you have no way to know whether you're looking at real intelligence or a confident hallucination.

The verification step closes that gap. It's not technical. It takes a few minutes. And it is the only way to know what you're actually working with.

The Proof Protocol

The framework I use for this is what I call the Proof Protocol. It has three levels, and most business owners stop at level one.

Level 1 — The Confirmation Question

Ask Codex: "What plugins do you have access to?"

Codex will list what it sees. This is useful as a baseline, but it is not verification. It is Codex reporting what it thinks is connected. That is not the same as those connections returning real data.

Level 2 — The Direct Access Question

Ask Codex: "Do you have access to my Gmail?" or "Can you access my Google Drive?"

Codex will confirm yes or no. This is one level better — it's a direct query about a specific tool. But it's still Codex self-reporting. And Codex can confirm access in principle while still being unable to retrieve the specific data you need in practice.

Level 3 — The Retrieval Test

This is the only level that counts.

Ask Codex to prove it. Not to confirm access — to demonstrate it with real data.

For Gmail: ask it to pull the last five emails you received from a specific sender, or the last three emails with a specific subject line. If Codex returns actual emails with actual content, the connection is functional.

For Google Drive: ask it to list the files in a specific folder by name. If it lists your actual files, the connection works.

For Google Calendar: ask it to return your next three scheduled events with titles and times. If it returns your real calendar data, you're good.

For Stripe: ask it to return the most recent transaction amount and the name of the customer.

If Codex stalls, gives a vague non-answer, or returns something that doesn't match your actual data — the plugin is not functioning at the depth you need. Don't move forward assuming it will work when it matters.

What to Do When the Test Fails

If Codex can't retrieve real data through a connected plugin, you have two paths.

Path 1: Reconnect and reauthorize

Sometimes the plugin connection degraded or the authorization lapsed. Disconnect the plugin completely, reconnect it, re-authorize with your credentials, and run the Level 3 test again. This resolves shallow connection failures.

Path 2: Investigate the integration depth

Some plugins are genuinely shallow. They confirm a connection but only expose limited data. In those cases, you either need API-level access — which Codex can help you configure — or you need to accept the limitation and not build workflows that depend on that data source.

The practical signal: if Codex can answer a simple, specific retrieval question with real data, you have functional access. If it can't, you don't — regardless of what the confirmation screen showed.

Why This Matters More Than Business Owners Realize

The verification step isn't just a setup technicality. It determines what Codex can actually do for your business.

Consider a prompt like: review the last 12 months of emails, identify every prospect who was sent a proposal, separate who closed from who didn't, and build a re-engagement strategy for the ones who went dark.

That is a single prompt. It takes seconds to issue. And it produces something that would take a human days to compile manually.

But it only works if Gmail access is real, not cosmetic. If the plugin confirmed but didn't actually connect at the data level, Codex either stalls, or worse, produces a fabricated answer that sounds reasonable and contains none of your actual data.

Business owners who verify plugins before building on them get to use prompts like that one. Business owners who skip verification find out the hard way — when they need the data and don't have it.

The Verification Checklist

Run this after connecting any plugin. Five minutes per plugin. Non-negotiable.

If any plugin fails the Level 3 test: reconnect, reauthorize, test again. If it fails again, treat it as limited access and don't build workflows that depend on it.

The Common Mistake

The mistake isn't connecting plugins carelessly. Business owners generally take the connection flow seriously. The mistake is conflating confirmation with access.

A checkmark means the handshake completed. It does not mean Codex can read your inbox, retrieve your files, or pull your financial data. Those are earned by running the Level 3 test — not assumed from the connection screen.

Spend the extra five minutes per plugin. It is the only thing standing between you and building an agentic system on a foundation you've never actually tested.

Before You Move to the Next Step

Once you've verified plugin access with real data retrieval, you're ready to move into the intelligence-gathering phase — having Codex actually read your business data and build a working model of how your business operates. That only works if the pipeline from plugin to Codex is functional, which is exactly what this step confirms.

The next step in the sequence: Run the Business Intelligence Gathering Skill.

If you haven't installed and connected your plugins yet, start there: Install and Connect Plugins.

Connecting a plugin is step one. Verifying it is step two. Most people only do step one, and they don't find out until much later.

Don't trust the checkmark. Make it prove itself.

For the complete framework, read the full guide. — Shanee

Additional Context: The Checkmark Lie: Why a Connected Plugin Doesn't Mean Codex Has Real Access

If you've spent any time setting up Codex, you've seen it — the plugin confirmation screen. You click connect, you log in, you authorize, and you get a checkmark. Codex says it has access. You move on.

That checkmark is not access. It's an introduction.

This is one of the most consequential misunderstandings I see business owners make when setting up their agent infrastructure. They treat plugin connection as plugin access. They are not the same thing, and conflating them means you're building on a foundation you've never actually tested.

For the complete framework on standing up Codex as an operational system, read the full guide. This post goes deep on one specific problem: what to do when a plugin says it's connected but isn't delivering real access.

Watch me explain this live — I walk through plugin verification in real time.

Why the Checkmark Exists and What It Actually Proves

When you connect a plugin to Codex, what happens at the technical level is a handshake. Codex and the external tool — Gmail, Google Drive, Stripe, whatever it is — exchange credentials and establish a protocol. That handshake can complete successfully while the actual depth of access remains shallow.

Some plugin integrations are built to give agents full programmatic access to the data inside the tool. Others are built to give agents just enough access to confirm the connection exists. The handshake completes either way.

Codex can only tell you what it was given. If the plugin was built as a shallow integration, Codex has a shallow connection. It will report that it has access because, technically, it does — just not the kind that's actually useful for agentic work.

The problem surfaces when you give Codex a real task. You ask it to pull 12 months of email history and identify every proposal you sent. It stalls. Or it gives you a vague, hallucinated answer that sounds plausible but references nothing real. You assume Codex is broken. What's actually broken is the assumption that the checkmark meant something it didn't.

The Proof Protocol: What Real Verification Looks Like

I call this the Proof Protocol, and it's simple: don't accept Codex's self-report. Make it demonstrate access with actual data.

There are two different tests, and most business owners only run the first one.

Test 1 — Existence Test (what everyone runs): Ask Codex: "Do you have access to my Gmail?" It says yes. You move on.

Test 2 — Retrieval Test (what almost no one runs): Ask Codex to pull something specific and real. "Show me the last 5 emails I received from a new lead." Or "Pull the most recent email from [client name]." Or "List every email I sent this week with the word proposal in the subject line."

If Codex retrieves actual emails that match what you know to be true, the plugin is functioning at a useful depth. If it stalls, fabricates, or gives you generic-sounding responses with no verifiable specifics, the connection is cosmetic.

The Retrieval Test takes 60 seconds. It will tell you more than any confirmation screen.

What Shallow Integration Actually Looks Like in Practice

The transcript from my live session referenced Gmail as an example of what deep plugin access enables. Here's the specific use case I walked through: ask Codex to review the last 12 months of emails, identify who was sent a proposal, who closed, and who didn't — then build a strategy to revive the leads who went dark.

That is a task that requires real, deep access to your inbox. Codex needs to read actual email content, not just confirm that a Gmail account is associated with the integration. A shallow connection cannot do this. It will either refuse the task or produce a response that sounds like it's working but contains no real data.

I've seen business owners get burned by this exact gap with QuickBooks. The plugin exists. The connection completes. But QuickBooks requires frequent re-authorization and returns inconsistent data even when access is technically granted. The integration was built by someone, at some point, for some level of access — but it doesn't deliver the reliable, deep data retrieval that agentic work actually requires. That's not a Codex failure. That's a shallow integration operating exactly as built.

The Three Outcomes When a Plugin Falls Short

When the Proof Protocol fails — when Codex can't retrieve real data from a connected tool — you have three options. Which one applies depends on the tool and the integration.

The first option — API access — is more accessible than it sounds. Codex can help you configure it. If a plugin gives you a shallow connection and you need real access, open a Codex chat, describe the limitation you're hitting, and ask it to walk you through setting up API-level access to that tool. This is not a task that requires a developer. It is exactly the kind of technical configuration Codex was built to handle for non-technical business owners.

The last option — migrating to a more agent-accessible tool — is the harder call, but sometimes the right one. My own experience transitioning from Fireflies to Google Meet for meeting transcripts is an example. Fireflies was flagged as inconsistent. Google Meet recordings and transcripts are more reliably accessible by agents. The migration made sense because reliable data access is more valuable to me than tool familiarity.

For more on evaluating tools through this lens, see what makes a tool agent-friendly vs. agent-hostile.

How to Run the Proof Protocol for Each Plugin You Connect

Do this for every plugin, not just the ones you're currently using for critical tasks. A plugin you think is connected might be the one Codex silently fails on six months from now when you ask it something important.

Gmail: Ask Codex to retrieve the last 5 emails from a specific sender or with a specific subject line. Verify the results against your actual inbox.

Google Drive: Ask Codex to list the files inside a specific folder by name. Verify the list matches what you see in Drive.

Google Calendar: Ask Codex to name your next three scheduled events. Verify against your calendar.

Stripe: Ask Codex to pull your last three successful payments, including the amount and customer name. Verify against your Stripe dashboard.

Meeting notes tools (Fireflies, Otter, etc.): Ask Codex to summarize the most recent meeting transcript it can access. Verify the summary against the actual transcript.

If any of these tests return no data, vague data, or hallucinated data, that plugin needs investigation before you rely on it for anything operational.

What "Verify Plugin Access by Testing It" Actually Costs You if You Skip It

Business owners skip verification for the same reason they skip most setup steps — it feels like extra work on top of work that already feels complete. You connected the plugin. Why would you need to test it?

Because the cost of skipping verification shows up later, when the task matters. Not during setup, when you have time to fix it. During a high-stakes prompt — pulling together a sales review, analyzing client communication patterns, generating a financial summary — when Codex silently fails and you don't immediately know why.

At that point, the diagnosis is harder. You're not in setup mode. You're in production mode. And the question becomes: did Codex make an error, or did the plugin never have real access? You have to backtrack to find out.

Verification during setup is 60 seconds per plugin. Diagnosis during production is significantly longer, and it interrupts actual work.

This connects to a broader principle about how to set up Codex: the Foundation Phase — verification included — is not administrative overhead. It is the load-bearing infrastructure that determines whether everything you build on top of it actually works. See the Foundation Phase explained in the full guide if you haven't gone through the full setup sequence yet.

The Adjustment: What to Do Right Now

If you've already connected your plugins and skipped verification, here's the correction:

1. Open a Codex session
2. Ask Codex what plugins it currently has access to — get the full list
3. For each plugin, run a Retrieval Test using real, specific data you can verify
4. Flag any plugin that fails the Retrieval Test
5. For flagged plugins: decide whether you're pursuing API access or investigating authorization scope
6. If a tool consistently fails and has no viable workaround, factor that into your tool evaluation going forward

This should take less than 30 minutes for a standard plugin stack. It is worth every minute.

The Principle

A confirmed connection is not confirmed access. And assumed access is not proven access.

Build on proof, not on checkmarks.

— Shanee

*