[CLI] Repeated skill-load warnings fill TUI during concurrent AICM skill refresh

What version of Codex CLI is running?

codex-cli 0.149.1

What subscription do you have?

Enterprise

Which model were you using?

No response

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

superset sh

Codex doctor report

What issue are you seeing?

Codex intermittently emits repeated skill-loading warnings that permanently accumulate in the TUI scrollback:
⚠ Skipped loading 1 skill(s)due to invalid SKILL.md files.
⚠ /Users//.agents/skills//SKILL.md: failed to read file: No such file or directory (os error 2)

The affected paths are managed by AICM in the shared ~/.agents/skills directory. The same paths often exist shortly after the warning is emitted, and the skill files are observed being rewritten sequentially during an AICM refresh.

The warning is misleading because the failure is a transient ENOENT/race, not necessarily an invalid SKILL.md. Codex also repeats the warning without deduplication, causing the TUI scrollback to slowly fill.

The separate “Cleaned all 15 stale tracked diffs” message appears to come from the Superset wrapper/session cleanup and is not part of the skill-loading failure.

What steps can reproduce the bug?

Uploaded thread: 01a03478-07ab-7c43-8c63-c9ad4429953d

What is the expected behavior?

Codex should tolerate transient ENOENT errors while the skill directory is being refreshed.

Possible acceptable behavior:

• read skills from a consistent snapshot;
• retry or defer transient missing-file errors;
• emit at most one deduplicated warning per persistent failure;
• distinguish unreadable/missing files from malformed SKILL.md files.

Warnings should not accumulate indefinitely in the TUI scrollback.

Additional information

No response

Start with the uploaded thread 01a03478-07ab-7c43-8c63-c9ad4429953d and trace the CLI skill-loading and TUI warning paths involved in the shared ~/.agents/skills refresh. Confirm the concurrent ENOENT behavior, then verify that transient failures do not produce misleading repeated warnings and that persistent failures are deduplicated.