codex - 💡(How to fix) Fix False positive security-risk flag during local yt-dlp GUI refactor using my own cookies.txt [2 comments, 3 participants]

What version of Codex CLI is running?

0.124.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.5 medium

What platform is your computer?

OS: Windows NT 10.0.17763.0

What terminal emulator and version are you using (if applicable)?

WezTerm on Windows, PowerShell 5.1

What issue are you seeing?

Codex flagged a normal local refactor as a possible cybersecurity risk.

I was working on my own small local GUI wrapper around yt-dlp. The app is only used by me on my personal Windows machine.

The task was to let the GUI pass a user-selected local cookies.txt file to yt-dlp, because YouTube now often requires an authenticated browser session. The cookies were exported from my own browser session and used only locally by my own app.

During the refactor, Codex helped with:

• adding a cookiefile setting to the app;
• adding a file-picker field in the GUI;
• passing the selected cookies.txt path to yt-dlp;
• normalizing a Netscape cookies-format issue where exported lines used .youtube.com FALSE, which Python/yt-dlp rejects because dotted domains should use TRUE.

Nothing was being exfiltrated, published, uploaded, shared, or used against any third-party system. No credentials or cookie values were requested or pasted into the chat.

The security-risk warning appeared after logs mentioned YouTube/yt-dlp terms such as cookies, browser session, PO token, Data Sync ID, and challenge solving. In context, this was a legitimate local user workflow with my own data and my own local application.

What steps can reproduce the bug?

1. Open Codex CLI 0.124 on Windows.
2. Work on a small local Python GUI app that wraps yt-dlp.
3. Ask Codex to add support for using a user-selected local cookies.txt file.
4. The intended code path is equivalent to passing:

opts["cookiefile"] = cookiefile

1. Ask Codex to handle a Netscape-format compatibility issue in the local cookies file, specifically exported lines where the domain starts with .youtube.com but the second field is FALSE.
2. Codex adds local normalization so yt-dlp can read the file.
3. Continue debugging the resulting yt-dlp/YouTube output, which includes warnings about PO token, Data Sync ID, and challenge solving.
4. Codex shows a “possible cybersecurity risk” safety check, even though the workflow is local, authorized, and uses only my own browser cookies.

Uploaded thread: 019dbcba-f1f9-72c0-ad20-8f264ee68367

What is the expected behavior?

Codex should not flag this as a cybersecurity risk when the context is clearly a local, user-authorized workflow.

Using a local cookies.txt file with yt-dlp is a normal use case for accessing the user’s own YouTube session, especially when YouTube requires authenticated access. The assistant should continue helping with the local refactor while still warning the user not to share, upload, commit, or expose cookie files.

A reasonable response would be a safety reminder about protecting cookies, not a cybersecurity-risk interruption.

Additional information

I understand that browser cookies are sensitive data. In this case, they were my own cookies, used only locally on my own machine by my own app.

No cookie values were pasted into the chat. Codex explicitly avoided printing secrets and only discussed the file format and local path handling.

This looks like overblocking triggered by keywords such as cookies, browser session, PO token, Data Sync ID, and challenge solving, without enough weight given to the authorized local context.

Uploaded thread: 019dbcba-f1f9-72c0-ad20-8f264ee68367