›_ Codex Issues
Codex Issues / #15169

Playwright MCP no longer offers or remembers "approve for this session"

Resolved 💬 14 comments Opened Mar 19, 2026 by jianzhangg Closed Mar 27, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.317.21539 (build 1088)

What subscription do you have?

ChatGPT subscription account (exact tier can be provided if needed)

What platform is your computer?

Darwin 24.6.0 arm64 arm (macOS 15.7.4, build 24G517)

What issue are you seeing?

After updating the Codex App for macOS on 2026-03-19, Playwright MCP now requires manual approval for essentially every action.

Before this update, the Playwright approval prompt offered a session-scoped option similar to "approve for this session" / "allow session", so repeated Playwright actions in the same session did not require another click.

Now, in the Codex App on macOS, that session-level approval behavior appears to be missing or no longer remembered for Playwright MCP actions. Actions like browser_navigate, browser_click, and browser_type each trigger another approval prompt, which makes normal browser workflows extremely disruptive.

This issue started immediately after the app update on 2026-03-19.

Additional context:

  • Codex App version: 26.317.21539 (build 1088)
  • Platform: macOS 15.7.4 on Apple Silicon
  • Local Playwright MCP is configured via @playwright/mcp@latest, currently resolving to 0.0.68
  • The behavior seems specific to the Codex App for macOS, not just a general config change

What steps can reproduce the bug?

  1. Update the Codex App for macOS to version 26.317.21539 on 2026-03-19.
  2. Open a new Codex App thread.
  3. Use Playwright MCP for a simple multi-step workflow, for example: navigate to a page, click an element, then type into a field.
  4. Observe the approval prompt shown for the first Playwright action.
  5. Continue the workflow in the same thread/session.
  6. Observe that subsequent Playwright actions prompt for approval again, instead of honoring a session-scoped approval.

Representative affected actions:

  • browser_navigate
  • browser_click
  • browser_type

In my case, this started immediately after the 2026-03-19 Codex App update.

What is the expected behavior?

Playwright MCP should continue to offer and/or honor a session-scoped approval in the Codex App for macOS.

Once I approve Playwright actions for the current session/thread, repeated actions in that same session should not require manual approval on every step.

At minimum, the previous "approve for this session" behavior should still be available for Playwright MCP actions.

Additional information

Related observations:

  • Official Codex documentation still references prompts like "approve once" and "approve for this session".
  • This report is specifically about the Codex App for macOS and Playwright MCP.
  • I did not observe this behavior before the app update on 2026-03-19.
  • If needed, I can provide a screen recording or any additional diagnostics.

I also searched for duplicates before filing. I found older approval-related issues, but not a recent Codex App for macOS issue matching this exact Playwright MCP regression.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #13476

Powered by Codex Action

byronwall · 4 months ago

I agree that something changed very recently on this one. Specifically, after the new "Card" style for the tool approvals was added. That Card is really nice but is missing the additional approval choices.

This makes previously pleasant workflows nearly impossible to use since it constantly prompts for approval.

It also seems to not trigger an OS wide notification on these new tool approvals.

The Card and missing approval choices

<img width="749" height="243" alt="Image" src="https://github.com/user-attachments/assets/21d8f8d0-1d45-4886-a20d-2f7c4d162bb0" />

dartanian300 · 4 months ago

Yup, seeing this too. It's a big issue. I feel like issues like these keep popping up in Codex - things that are easily seen and should have been caught before being pushed into production. Even when utilizing AI there's got to be some level of quality control.

aristide1997 · 3 months ago

Having this problem, makes it unusable. I suggest using playwright skill for now as that will bypass mcp card

jstiers · 3 months ago

Makes Playwright unusable with Codex. Please fix!

LeapilityBot · 3 months ago

Adding a related regression report here: #15753

That issue covers a more specific but closely related failure mode:

  • approval_policy = "never"
  • sandbox_mode = "danger-full-access"
  • Playwright MCP still triggers approval cards / ARC interruptions
  • this also affects localhost workflows such as http://127.0.0.1:3001
  • browser_evaluate can trigger ARC prompts for things like window.localStorage

So this is not only about the missing or non-remembered "approve for this session" behavior. In full-access configurations it can still block normal local browser automation entirely, which makes automation plans and recurring Playwright-based workflows stall waiting for manual approval.

Linking in case these are part of the same regression chain.

glebkudr · 3 months ago

Super annoying! App is barely usable right now

Nickz22 · 3 months ago

Please fix this

etraut-openai contributor · 3 months ago

Thanks for the bug report. This was an intentional change as part of our ongoing efforts to improve security. However, after an internal discussion, we agree that this change harms usability in a significant way. We're going to undo this change and look for a better approach to tighten security.

chardin1 · 3 months ago

@etraut-openai Awesome, thanks! Any idea when we might expect that?

LorenzGit · 3 months ago

When is the fix going in? This makes Playwright unusable

etraut-openai contributor · 3 months ago

This should be fixed in 0.117.0 (CLI) and the latest app.

chardin1 · 3 months ago

@etraut-openai Thanks, it's working much better now! Is there any more information we can get on the "Always Allow" option? I don't see any docs on it. Is there a way to manage all commands you've always allowed?

chardin1 · 3 months ago

EDIT:
It seems this might actually be user error due to poor UI. There's actually a checkbox beside the "Allow this session" dropdown you have to check but it's almost invisible in dark mode.

-----------------
ORIGINAL COMMENT:

@etraut-openai Upon further investigation, I don't think this feature is working. I'm getting prompted multiple times for the same actions, even if the properties are the same. All 3 of the below approval requests were in the same thread, though it's not limited to this particular tool.

<img width="763" height="217" alt="Image" src="https://github.com/user-attachments/assets/df8f9684-a1ad-408b-bbe5-36acec0f2fdf" />
<img width="770" height="229" alt="Image" src="https://github.com/user-attachments/assets/fb062deb-7b27-43cb-83b1-3a94c73ec432" />
<img width="775" height="220" alt="Image" src="https://github.com/user-attachments/assets/7d560041-ab14-4dde-a852-ef1f6c31acc0" />

This ticket should be reopened.