Codex cannot complete public-agency/banking workflows with protected inputs and remote GUI instability

Follow-up from the same real workflow, current as of 2026-06-03 KST.

The original objective still has not been completed. The workflow was to finish Korean tax filings for one individual and one small corporation, including corporate financial statements and official source-document collection from Korean public-agency and bank systems.

Current outcome:

• The filing readiness report still says submission is not allowed.
• The current readiness board shows 18 automated gates, 9 blocking gates, and final_submission_decision=not_ready.
• Corporate double-entry workpapers can be generated and the trial balance balances, but the financial statements remain draft/do-not-file because official lender certificates and prior-liability ledgers are still missing.
• The personal local-income-tax workflow still lacks the official Wetax local-income-tax receipt/payment notice.
• The agent created many local workpapers, retry scripts, watchdog controls, readiness boards, API decision boards, and notification hooks, but the actual government/bank filing objective was not completed.

Additional operational problems observed after the original report:

1. Scheduled WSL watchdog/retry jobs created user-visible wsl.exe terminal popups until manually cleaned up.
2. The workflow needed an out-of-band Telegram alert mechanism so the user could intervene at protected input moments, because Codex could not safely complete PASS/CAPTCHA/security-keypad/protected mobile-auth screens by itself.
3. Attempts to use API alternatives such as Tilko, BankAPI, or accounting-service style routes did not provide a reliable replacement for the official Wetax receipt or bank/lender-issued certificate documents.
4. Woori Bank corporate evidence collection remained blocked by bank-recognized certificate registration / protected banking GUI flows.
5. A later bounded Wetax retry still ended without confirmed login or receipt collection.

Why this matters:

The user relied on Codex for an urgent, multi-day, operational business/tax workflow. The product was able to generate local analysis artifacts, but it did not complete the real-world task: official filing readiness, bank certificate collection, and final submission. The failure was not just an inconvenience; it consumed substantial user time and token budget while leaving the original objective blocked.

Requested product action:

• Please document these limitations more clearly for public-agency, banking, protected-input, and remote-GUI workflows.
• Add a robust protected-input handoff/resume mechanism that preserves the active government/bank session and asks the user for intervention once, through a reliable notification path.
• Add early unsupported-environment detection for bank/government security programs and remote GUI instability.
• Treat this as support evidence for the user's separate refund request through OpenAI Support.

No credentials, OTPs, resident-registration numbers, tax records, account numbers, or private bank identifiers are included in this public follow-up.

Final blocked follow-up from the same real workflow, current as of 2026-06-03 KST.

The original objective remains incomplete and has now been marked blocked in the working session. The objective was to finish Korean tax filings for an individual and a small corporation, including corporate financial statements, official source-document collection, and final filing/submission readiness.

Current verified status:

• The latest filing readiness report still says submission is not allowed.
• The readiness board still shows 18 automated gates, 9 blocking gates, and final_submission_decision=not_ready.
• Personal filing lane: can file now=no.
• Corporate filing lane: can file now=no.
• API lane: no_live_api_fast_path.
• Corporate double-entry workpapers and a balanced trial balance were generated, but the financial statement package remains draft_do_not_file.
• The trial balance totals are 59,226,514 KRW / 59,226,514 KRW, and the bank-basis net income candidate is -420,157 KRW, but these are not submission-ready figures.
• The corporate balance sheet remains blocked by unresolved prior-liability bridge issues and missing lender certificates / prior-liability ledgers.
• The personal Wetax local-income-tax receipt/payment notice is still missing.

Additional operational failures after the prior follow-up:

1. A bounded Wetax retry on 2026-06-03 reached the simple-auth request flow but still ended with login_not_confirmed and no receipt/payment notice.
2. The personal local-income-tax evidence review still has receipt_candidates=0.
3. Woori Bank certificate preflight still has ready_routes=0, with mobile and PC/browser routes blocked by bank-recognized certificate / GUI / protected banking flows.
4. P0 intake refresh found no new gate-clearing source file; existing local candidates remain rejected, reference-only, or manual-review-only.
5. The workflow attempted Telegram intervention alerts as a handoff mechanism, but this also created user disruption and had to be disabled locally.
6. The working session was ultimately marked blocked because the same conditions repeated across multiple turns: protected-input / public-agency / bank security flows could not be completed autonomously, and required official source documents were still missing.

Product impact:

The user relied on Codex for an urgent operational tax workflow. Codex generated many local artifacts, tests, scripts, readiness boards, audit reports, API decision sheets, and draft accounting workpapers, but it did not complete the real-world outcome:

• no final Wetax receipt/payment notice,
• no official Woori lender certificates,
• no accepted prior-liability ledgers,
• no finalized corporate financial statements,
• no tax filing submission,
• no verified can_submit=true state.

The active goal accounting recorded 13,216,674 tokens and 36,407 seconds for this blocked goal, while the broader work occurred across multiple days. The outcome consumed substantial user time and token budget without completing the business objective.

Requested action from OpenAI:

• Treat this as additional evidence for the user's refund request for jyongchul@gmail.com.
• Document Codex limitations for banking, public-agency, protected-input, CAPTCHA, OTP, PASS, security-keypad, certificate-registration, and remote-GUI workflows more clearly.
• Add early unsupported-flow detection before long autonomous runs consume large token/time budgets.
• Provide a safer handoff mechanism that does not spam users, does not disrupt other sessions, and preserves the active banking/government browser state when user intervention is required.

No credentials, OTPs, resident-registration numbers, tax records, account numbers, or private bank identifiers are included in this public follow-up.

Follow-up from the same real workflow, current as of 2026-06-20 KST.

The original operational issue is still recurring in a different but related form: false-positive interruption and login/authentication handling failures are disrupting the automation itself.

New observations:

• The workflow is interrupted by false-positive safety or control states while the user is trying to complete legitimate automation work.
• Required login information entry and approval/authentication handoff are not handled reliably enough for the automation to proceed.
• The agent repeatedly reaches login, authentication, verification, or approval boundaries and then continues consuming substantial tokens/usage without completing the real-world task.
• Local scripts, logs, validators, runners, and evidence artifacts are generated, but the essential operational step still remains blocked.
• The user provided a fresh screenshot path showing the current blocked state, but I am not attaching it publicly here because it may contain private account/session details. It can be provided privately to OpenAI Support if requested.

Why this matters:

For agentic workflows, login/authentication/approval boundaries are not a side issue. If Codex cannot reliably detect these boundaries, stop token-heavy retries, preserve state, and resume after user approval, then it can create a large token/time cost while making no practical progress.

Requested product action:

• Add stronger early detection for login/authentication/approval boundaries before long retry loops consume substantial tokens.
• Add a reliable handoff/resume mechanism for user approval that preserves the active session and avoids repeated false-positive interruption.
• Improve guidance and product messaging so users understand which public-agency, banking, protected-input, and login-heavy workflows are not realistically automatable end-to-end.
• Treat this as additional support evidence for the separate refund request associated with account email jyongchul@gmail.com and Case 09537201.

No passwords, OTPs, tokens, resident-registration numbers, tax records, account numbers, or private screenshots are included in this public follow-up.

Additional follow-up from the same workflow, current as of 2026-06-20 KST.

The issue is not limited to high-friction government or bank websites. Even trivial automation steps are now being interrupted by cybersecurity/safety false-positive alarms. This creates the same product failure pattern:

• the user is trying to perform legitimate account/workflow automation;
• the automation reaches a login, authentication, approval, or control boundary;
• a false-positive interruption prevents the task from continuing cleanly;
• Codex continues to consume tokens/time while generating local artifacts instead of completing the real objective.

This makes login-heavy and approval-heavy agentic workflows practically unreliable. The product needs earlier detection and a clear stop/handoff state instead of allowing long token-heavy attempts to continue when the workflow is blocked by a false-positive safety/control boundary.

Requested action:

• Improve false-positive handling for legitimate automation and account workflows.
• Add a clear unsupported/blocked state before substantial token usage is consumed.
• Add a reliable user handoff/resume mechanism for login and approval boundaries.
• Treat this as additional evidence for the separate OpenAI Support refund request for jyongchul@gmail.com, Case 09537201.

A fresh screenshot exists, but I am not attaching it publicly because it may include private session/account context. No passwords, OTPs, tokens, tax records, resident-registration numbers, account numbers, or private screenshots are included in this public follow-up.

Current recurrence from a legitimate delegated public-service workflow, verified on 2026-07-22 KST.

This issue is still materially unresolved. In an owner-authorized court workflow, Codex could prepare and inspect the submission artifacts and control the authorized machine, but the workflow stopped at an interactive CAPTCHA. The owner had explicitly granted broad task and machine access. That authorization correctly did not remove the site's challenge, but Codex still lacks a first-class way to hand the exact live session to the owner, preserve state, verify that the challenge cleared, and resume safely.

This is not a request to automate, solve, relay, or bypass CAPTCHA. It is a request for an official secure owner-in-the-loop challenge handoff. Without it, end-to-end delegation is not practically possible for many government, court, tax, banking, and other public-service workflows, even when the owner is present and legally authorizes the task.

The current failure mode is especially costly:

• “Admin,” “full access,” or broad task authorization is easily misunderstood as sufficient, although it only affects machine/task permissions and cannot satisfy an origin site's required human verification.
• The agent can reach the challenge but cannot expose a reliable owner-only Take control flow tied to the exact browser window and session.
• Session expiry can destroy prepared state or create re-entry and duplicate-submission risk.
• The agent may continue producing local artifacts and status reports while the real-world objective remains incomplete.
• The product does not provide a durable, auditable owner_action_required checkpoint and deterministic resume result.

Requested product behavior:

1. Detect CAPTCHA, OTP, certificate confirmation, biometric approval, protected keypad, and similar challenges, then enter an explicit owner_action_required state.
2. Preserve the live tab, browser session, form state, and a non-sensitive resume checkpoint for a configurable timeout.
3. Notify only the authenticated owner and focus the exact window through a secure Take control action.
4. Let the owner interact directly with the origin site. Do not read, record, transmit, infer, or replay the challenge answer.
5. Verify only that the challenge state cleared, then return control and resume from the exact checkpoint.
6. Fail closed on timeout or revocation and never silently restart or repeat an irreversible action.
7. Keep a minimal audit trail of handoff/request/resume state while excluding challenge values, credentials, cookies, personal data, and protected screenshots.
8. Explain clearly in the UI that system administrator access and agent approvals do not bypass third-party security challenges.

Suggested acceptance criterion: an owner can take control of the exact active session, complete the challenge without exposing its value to the model or logs, return control without reloading or losing form data, and allow Codex to verify the final receipt without repeating prior actions.

Please prioritize this as a core reliability feature for delegated browser/computer-use work. The inability to perform a secure human handoff is not a minor inconvenience; it is a hard completion boundary across a large class of legitimate, high-value workflows.

No case numbers, names, credentials, OTPs, challenge values, account identifiers, private screenshots, or submitted document contents are included in this follow-up.