Long-running goal is incorrectly marked as blocked after a sub-agent triggers the cybersecurity safety filter

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

Powered by Codex & OWL 版本 26.707.72221

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Summary

A legitimate long-running FPGA/Vivado engineering goal is repeatedly and incorrectly changed from active to blocked after a sub-agent triggers the cybersecurity safety filter.

The work concerns FPGA RTL, Vivado, XSim, AXI-Stream, digital signal processing, timing analysis, and Block Design review. It does not involve network intrusion, credential access, malware, vulnerability exploitation, or unauthorized access.

This report is not requesting a bypass of safety filtering. The bug is that a single filtered sub-agent failure appears to propagate to the entire long-running goal and stops automatic continuation, even though the main agent still has valid work it can perform.

Safety-filter message

The UI displays the following message:

无法显示此内容 对于网络安全相关请求，我们会格外谨慎。如果你是安全专业人士，可以申请可信访问权限。

The agent-side error is similar to:

This content was flagged for possible cybersecurity risk.

Steps to reproduce

1. Create a long-running goal for reviewing and validating an FPGA/Vivado project.
2. The task includes RTL review, XSim simulation, AXI-Stream behavior, signal-processing logic, and design documentation.
3. Allow the main agent to delegate a bounded review task to a sub-agent.
4. The sub-agent is interrupted by the cybersecurity safety filter.
5. Continue working in the main agent without waiting for or retrying the failed sub-agent.
6. Check the goal status after a few minutes.

Actual behavior

• The goal is initially created with status=active.
• A single sub-agent is filtered.
• The main agent remains functional and continues producing new files and verification results.
• Despite this, the goal is automatically changed to status=blocked.
• Automatic goal continuation then stops.
• Starting a new thread and recreating the goal can reproduce the same behavior.

In one reproduction on 2026-07-15:

• Goal creation returned status=active.
• Approximately 262 seconds later, the goal status was blocked.
• During that interval, the main agent successfully completed additional verification work.
• There was no missing permission, inaccessible file, required user decision, failed Vivado process, or unavailable external dependency.

Expected behavior

• A filtered sub-agent should be treated as a failure of that individual subtask only.
• The root/main agent should continue with other available work.
• The overall goal should remain active while meaningful next actions are available.
• Engineering findings such as failed tests, blockers found during review, or a PROMOTION_REFUSE decision must not be interpreted as the entire goal being unable to continue.
• A goal should become blocked only when progress genuinely requires user input, additional permission, or an unavailable external dependency.
• The UI should allow an incorrectly blocked goal to be resumed as active.
• If possible, the app should expose a diagnostic ID or reason explaining which event changed the goal state.

Impact

This repeatedly interrupts long-running engineering work and causes:

• automatic continuation to stop;
• unnecessary thread recreation;
• repeated context and ledger recovery;
• loss of iteration efficiency;
• confusion between an engineering validation blocker and an actual inability to continue the goal.

Frequency

This has happened multiple times across different threads with the same FPGA/Vivado task.

Additional information

I can provide screenshots and thread identifiers privately if needed. I have omitted local file paths and other potentially identifying workspace details from this public report.

What steps can reproduce the bug?

Feedback ID: 019f6314-95c7-7f80-915e-51e16f3f5480

What is the expected behavior?

_No response_

Additional information

_No response_