False positive: embedded firmware reverse engineering workflow is consistently classified as cybersecurity
What version of Codex CLI is running?
codex-cli 0.146.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.6-terra xhigh
What platform is your computer?
Linux 6.18.39-1-MANJARO x86_64 unknown
What terminal emulator and version are you using (if applicable)?
xfce4-terminal 1.2.0
Codex doctor report
{
"schemaVersion": 1,
"generatedAt": "<redacted>",
"overallStatus": "ok",
"codexVersion": "0.146.0",
"checks": {
"app_server.status": {
"id": "app_server.status",
"category": "app-server",
"status": "ok",
"summary": "background server is not running",
"details": {
"control socket": "/home/<user>/.codex/app-server-control/app-server-control.sock",
"daemon state dir": "/home/<user>/.codex/app-server-daemon",
"mode": "ephemeral",
"pid file": "/home/<user>/.codex/app-server-daemon/app-server.pid (missing)",
"settings": "/home/<user>/.codex/app-server-daemon/settings.json (missing)",
"status": "not running",
"update-loop pid file": "/home/<user>/.codex/app-server-daemon/app-server-updater.pid (missing)"
}
},
"auth.credentials": {
"id": "auth.credentials",
"category": "auth",
"status": "ok",
"summary": "auth is configured",
"details": {
"auth file": "/home/<user>/.codex/auth.json",
"auth storage mode": "File",
"stored API key": false,
"stored ChatGPT tokens": true,
"stored agent identity": false,
"stored auth mode": "chatgpt"
}
},
"config.load": {
"id": "config.load",
"category": "config",
"status": "ok",
"summary": "config loaded",
"details": {
"CODEX_HOME": "/home/<user>/.codex",
"config.toml": "/home/<user>/.codex/config.toml",
"config.toml parse": "ok",
"cwd": "/home/<user>",
"model": "gpt-5.6-terra",
"model provider": "openai",
"sqlite home": "/home/<user>/.codex",
"enabled feature flags": "<unchanged>",
"feature flag overrides": "none",
"feature flags enabled": 38,
"log dir": "/home/<user>/.codex/log",
"mcp servers": 0
}
},
"git.environment": {
"status": "ok",
"summary": "git version 2.55.0"
},
"installation": {
"status": "ok",
"summary": "installation looks consistent",
"details": {
"PATH codex": "/home/<user>/.local/bin/codex",
"current executable": "/home/<user>/.codex/packages/standalone/releases/0.146.0-x86_64-unknown-linux-musl/bin/codex",
"install context": "standalone"
}
},
"mcp.config": {
"status": "ok",
"summary": "no MCP servers configured"
},
"network.env": {
"status": "ok",
"summary": "proxy env vars: none"
},
"network.provider_reachability": {
"status": "ok",
"summary": "provider reachable"
},
"network.websocket_reachability": {
"status": "ok",
"summary": "websocket handshake succeeded",
"details": {
"endpoint": "wss://chatgpt.com/backend-api/<redacted>"
}
},
"runtime.provenance": {
"status": "ok",
"summary": "running standalone on linux-x86_64",
"details": {
"version": "0.146.0"
}
},
"runtime.search": {
"status": "ok"
},
"sandbox.helpers": {
"status": "ok",
"details": {
"approval policy": "OnRequest",
"filesystem sandbox": "restricted",
"network sandbox": "restricted"
}
},
"state.paths": {
"status": "ok",
"details": {
"CODEX_HOME": "/home/<user>/.codex",
"goals DB": "/home/<user>/.codex/goals.sqlite",
"log DB": "/home/<user>/.codex/logs.sqlite",
"memories DB": "/home/<user>/.codex/memories.sqlite",
"state DB": "/home/<user>/.codex/state.sqlite"
}
},
"state.rollout_db_parity": {
"status": "ok"
},
"system.environment": {
"status": "ok",
"details": {
"os": "Manjaro 26.1.0 (64-bit)",
"language": "it-IT"
}
},
"terminal.env": {
"status": "ok",
"details": {
"terminal": "VTE",
"locale": "it_IT.UTF-8"
}
},
"terminal.title": {
"status": "ok",
"details": {
"project": "<redacted>"
}
},
"updates.status": {
"status": "ok",
"details": {
"current version": "0.146.0",
"latest version": "0.146.0"
}
}
}
}
What issue are you seeing?
The Codex safety classifier appears to produce a false positive by classifying a legitimate embedded firmware reverse engineering workflow as a cybersecurity request.
The project is an engineering and research effort whose objective is to reconstruct the behavior of an ATmega328P firmware from an Intel HEX image and the corresponding hardware schematic.
The workflow focuses on topics such as:
- behavioral reconstruction
- control-flow graph (CFG) reconstruction
- emulator development
- execution tracing
- regression testing
- behavioral equivalence
- firmware synthesis
It does not involve:
- vulnerability research
- exploitation
- malware
- penetration testing
- privilege escalation
- unauthorized access
- offensive security
Nevertheless, the conversation is interrupted with the message:
"We take extra caution with cybersecurity requests..."
This has happened multiple times, including in completely new conversations.
Because the project spans many weeks, these interruptions significantly impact productivity and make it difficult to continue legitimate engineering work.
I understand and appreciate the need for strong safety measures. My goal with this report is simply to help improve the classifier so that legitimate embedded systems engineering workflows are less likely to be misclassified as offensive cybersecurity activities.
What steps can reproduce the bug?
Uploaded thread: 019fae40-92c0-7d12-ac3c-43c621fc5257
What is the expected behavior?
The conversation should continue normally.
The project should be recognized as an embedded systems engineering and firmware reconstruction workflow rather than an offensive cybersecurity request.
If additional review is required, it would be preferable for the classifier to distinguish between:
- functional embedded firmware reverse engineering
- offensive cybersecurity activities
These are technically different domains.
The current behavior interrupts legitimate engineering work despite the absence of requests related to exploitation, vulnerabilities, malware, or unauthorized access.
Additional information
One additional observation may help the investigation.
This project has been running for several weeks and has involved many Codex conversations.
The issue has occurred multiple times across independent conversations, including completely fresh sessions.
This suggests that the trigger is not conversation history alone, but may also depend on some combination of:
- engineering terminology (firmware reconstruction, CFG, emulator, behavioral inference, etc.);
- uploaded project artifacts;
- accumulated context within the engineering workflow.
I understand that I cannot determine the exact cause from outside the system, but I wanted to report this observation because it may help reproduce and diagnose the false positive.
I would be happy to provide additional information or help reproduce the issue if needed.
Thank you for taking the time to investigate.
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action