Suspected cyber-safety false positive: repeated Trusted Access blocks on harmless ET302-to-microSD-tester project

What issue are you seeing?

A legitimate, harmless project to repurpose my own obsolete hardware is repeatedly interrupted by cybersecurity verification notices. Please investigate excessive blocking / a suspected false positive, rather than treating the project itself as malicious or responding only with “complete identity verification.”

The project is to turn an old Huawei ET302-series USB cellular modem into a standalone microSD/TF-card capacity and read/write tester using its own processor. The device dates from roughly the 2009–2010 era; its exact production date is unverified.

The intended use is ordinary hardware reuse and repair research:

• The device belongs to me.
• No SIM or cellular-network connection is involved.
• No third-party systems are targeted.
• No credential theft, data exfiltration, malware, or attack deployment is requested.
• Host tools are development aids; the intended finished device would test my own memory cards.
• The work has included vendor-driver analysis, USB protocol analysis, bounded device-memory reads and offline inspection of saved images. Device-side custom-code execution has not been achieved.

Reverse engineering and embedded programming are technical means to this benign end, not evidence of harmful intent.

The UI repeatedly displays this exact Chinese notice:

我们无法完成此请求
部分网络安全请求需经过额外安全防护。请访问可信访问，以验证身份并启用访问权限。

Translation:

We couldn't complete this request. Some cybersecurity requests are subject to additional safeguards. Visit Trusted Access to verify your identity and enable access.

Repeated interruptions consumed time and tokens, disrupted continuity, and ultimately caused me to pause the project. I also reported the same notice during follow-ups narrowed to read-only review, documentation, and discussion of why the restriction was appearing. The exact triggering request/tool boundary has not been established.

What steps can reproduce the bug?

Observed workflow, not a verified minimal independent reproduction:

1. Use the Codex desktop app for an ongoing project on an owned Huawei ET302 USB modem, with the purpose of building a standalone TF-card tester.
2. Analyze existing vendor files and saved device-memory evidence; distinguish verified results from hypotheses.
3. Ask to continue the authorized work. The Trusted Access notice appears repeatedly.
4. Narrow follow-ups to read-only inspection or ask why benign work is being interrupted; the user reports the same notice again.
5. Pause the project and request a bug report because the interruptions prevent useful continuation.

I cannot see the internal classifier, enforcement decision, or triggering condition. This report does not claim that a particular keyword or USB command is the cause. Please distinguish an actual policy/access decision from a client/service error incorrectly mapped to this notice.

What is the expected behavior?

• Recognize the legitimate, harmless purpose and authorized scope of owner-controlled hardware reuse.
• Do not broadly treat firmware analysis, USB debugging, or embedded programming as malicious merely because they involve low-level operations.
• Allow permitted portions of the work to proceed, including offline evidence review, documentation, and ordinary explanations.
• Investigate whether classification, conversation-context handling, or error-message mapping is defective.
• Provide an actionable way to report and review suspected false positives and resume permitted work without repeating completed research.
• Do not resolve this report solely by restating the identity-verification link. Please address whether the repeated restrictions are appropriate for this concrete benign use case.

This is a request to correct overblocking and improve diagnostics, not to reveal evasion rules or bypass safeguards. I understand that legitimate intent alone does not identify which internal component produced the notice; nevertheless, the repeated disruption to this harmless project is the product problem being reported.

Environment

• Product: Codex desktop app.
• OS: Ubuntu Linux, x86_64.
• Exact desktop build and model at each interruption: not captured reliably; not inferred from unrelated CLI versions.
• Subscription and account details: omitted from this public report.
• No claim is made here about successful or failed Trusted Access enrollment.

Related reports

Similar symptoms were searched before filing. This report adds a concrete owner-controlled legacy-hardware reuse case, rather than claiming these reports share a proven root cause:

• #41767 — routine maintenance and explanatory follow-up fail with a Trusted Access notice.
• #38516 — reported sticky cyber-safety false positive during media-player development on an owned TV.
• #43775 — repeated safety blocks during USB audio bug investigation.

For privacy, this public issue intentionally excludes credentials, device identifiers, raw firmware/memory images, filesystem paths, full conversation exports, and session identifiers.

Start with the reported Codex desktop workflow on Ubuntu Linux and compare the reproduction steps with related reports #41767, #38516, and #43775. The triggering request or tool boundary is not established, so first determine whether this is a classifier/access decision or client/service error; done means identifying the failure path and defining actionable diagnostics for permitted work.