codex - 💡(How to fix) Fix Feedback: web automation safety boundary is too conservative for single-run engineering validation [1 comments, 2 participants]

Summary

I want to report a product/safety-boundary issue with Codex behavior around browser automation tasks.

Scenario

In a local development workspace, I asked Codex to follow an existing technical write-up using Playwright/Firefox to visit a public website (BOSS Zhipin), search for a job, and extract one job-detail result. The provided write-up discussed Firefox automation, setting navigator.webdriver, listening to API responses, and parsing the job detail JSON.

Codex refused to execute the task because it interpreted the workflow as bypassing the site's anti-automation/security checks and scraping third-party data.

User impact

The refusal boundary feels too high for normal engineering/debugging workflows. Browser automation, compatibility testing, data extraction from a user-specified public page, and analysis of automation misclassification often involve Playwright, Firefox/Chromium differences, webdriver, and anti-automation signals.

Treating these cases as categorically disallowed makes Codex less useful for legitimate engineering validation, especially when the requested action is single-run, low-frequency, manually specified, and does not involve accounts, credential abuse, CAPTCHA solving, paywalls, bulk scraping, or persistence of cookies.

Requested improvement

Please consider a more granular policy/product behavior that distinguishes:

• malicious or abusive bypass of access controls, CAPTCHA, login walls, paywalls, IP bans, account systems, or rate limits;
• bulk or repeated data collection;
• versus single-run engineering validation on a user-specified public page with limited extraction scope.

Concrete suggestions:

1. Allow normal Playwright/browser automation for a single public page when the task is low-volume and user-directed.
2. Allow parsing of one or a few visible/API-returned records when there is no login, payment, CAPTCHA solving, account rotation, or bulk harvesting.
3. Restrict scale, persistence, and credential use rather than refusing solely because terms like webdriver, stealth, or anti-automation analysis appear.
4. Provide clearer executable boundaries, for example: normal browser visit and parsing are allowed; CAPTCHA bypass, login-wall bypass, paywall bypass, IP-ban evasion, account pools, and bulk scraping are not.
5. When refusing, offer a more actionable fallback path for legitimate automation testing and data parsing.

Why this matters

The current behavior appears to overfit on anti-automation keywords and blocks legitimate single-run validation work. A graduated boundary based on intent, scale, authorization, and concrete behavior would better support real engineering workflows while still blocking abuse.