Abusive Skills/list polling

I am experiencing an extreme CPU usage in windows 10 with 0.4.71, I think it might be related.

Thanks for the bug report. This is definitely a consequence of #10478, but it's not a polling issue. That PR added support for a file watcher, which uses file-system-level events to detect changes. There's no polling involved. What you're seeing seems to indicate that we're receiving repeated file change events.

We're not able to repro this, so I'd appreciate your help in figuring out the root cause of this.

Are you able to repro this with the latest version of the CLI, by any chance? If so, that will make it easier to diagnose.

@Neuro-Dynamics, are you using WSL or native Windows?

Thanks for the bug report. This is definitely a consequence of #10478, but it's not a polling issue. That PR added support for a file watcher, which uses file-system-level events to detect changes. There's no polling involved. What you're seeing seems to indicate that we're receiving repeated file change events. We're not able to repro this, so I'd appreciate your help in figuring out the root cause of this. Are you able to repro this with the latest version of the CLI, by any chance? If so, that will make it easier to diagnose.

maybe use remote-ssh will make this bug
<img width="1139" height="538" alt="Image" src="https://github.com/user-attachments/assets/512dd3b5-17e4-4583-9b98-b986ada77923" />

@Neuro-Dynamics, are you using WSL or native Windows?

WSL

("Run in WSL" toggle active in VS Code Codex extension).

I do not get the Skills/list output shown above. My issue might be different.

I first investigated this after seeing persistent local log spam (skills cache cleared (1 entries) repeating while idle in ~/.codex/log/codex-tui.log). From that symptom, I traced repeated invalidation churn in skills watcher handling, then connected it to this issue and the watcher changes in #10478.

I implemented a candidate mitigation in my fork:

• branch: https://github.com/GraciousGazelles/codex/tree/fix/skills-live-reload-10831
• compare vs upstream main: https://github.com/openai/codex/compare/main...GraciousGazelles:fix/skills-live-reload-10831

Scope of changes: core watcher/invalidation path (file_watcher, thread_manager, skills::manager) plus live-reload test coverage update.

Local validation (single Linux host, this machine only, CLI/core repro):

• before: skills cache cleared (1 entries) about once per second while idle
• after: 0 occurrences in 12s and 30s samples, with normal session activity logs still present

I have not fully validated the VS Code extension matrix yet, so this is a likely related root-cause mitigation rather than a full cross-platform confirmation. If useful, I can open a draft PR from this branch.

@GraciousGazelles, thanks for doing that analysis! I looked at the change on your branch. Most of your change appears to be an attempt to mitigate the problem, but I'd like to understand the root cause.

Within the file_watcher module, you added a log statement:

debug!(
    event_kind = ?event.kind,
    event_paths = ?event.paths,
    event_attrs = ?event.attrs,
    "file watcher received relevant filesystem event"
);

I'd really like to know what you see as the output. Does it seem to indicate that there are repeated writes to a file within your workspace?

@etraut-openai thanks for following up, and sorry I did not include this detail earlier.

Context: I originally dug into this because I tend to keep multiple Codex sessions open, and I noticed this log line was firing at roughly ~1 line/sec per running instance (so with ~7 idle sessions it was ~7 lines/sec), which made the spam very obvious.

On the file watcher received relevant filesystem event line: it is emitted only when Codex classifies a notify event as "relevant" for skills (i.e. it produced at least one skills-path hit). The log prints the raw event_kind, event_paths, and event_attrs from notify; it is not inherently "a write happened" so much as "this event was treated as semantic".

A representative example looks like:

DEBUG codex_core::file_watcher: file watcher received relevant filesystem event event_kind=Modify(Data(Any)) event_paths=["~/.codex/skills/_evidence_watch/SKILL.md"] event_attrs=EventAttributes { inner: None }

To answer "does this indicate repeated writes?", I ran two controlled captures locally on Linux against a SKILL.md under the skills root:

• Access/read storm with zero writes: 0 "relevant filesystem event" lines.
• Same access/read storm plus exactly two deliberate writes: exactly 2 "relevant filesystem event" lines, both Modify(Data(Any)) on that file.

So in this repro, I am not seeing spontaneous repeated writes; when that debug line shows up, it tracked real writes 1:1.

For upstream validation / root-cause: I added a regression test that simulates an access-only event storm (with multiple subscribers) and asserts it must not broadcast SkillsChanged, and then asserts a real semantic Modify(Data(_)) does broadcast. That test fails against upstream baseline behavior and passes with the watcher change.

I also included a small follow-up refinement plus tests to make this durable: some backends report real writes as Access(Close(Write)), so the filter keeps Close(Write) semantic while continuing to suppress other access-only noise. This preserves reload-on-write behavior, but avoids access-only storms driving the per-instance ~1 Hz invalidation/log churn (and downstream skills/list activity).

To be explicit, this is a root-cause fix in watcher event classification (not a rate-limit or logging mitigation), validated by upstream-fail / fix-pass regression behavior while preserving real write semantics.

Just getting to notifications here, thanks for the discussion on this issue.
I'm running Windows 11 with Remote into local WSL2.

If there is a patch at any point, I'll run a beta. Please provide full instructions to ensure we don't get caught up in secondary issues related to installation.

Thanks all!

@GraciousGazelles, thanks for the details. I merged this PR which I'm hoping will help fix this issue. Perhaps you and/or @TonyGravagno could verify? It's included in 0.99.0-alpha.11, which was just published.

@etraut-openai thanks for the quick turnaround on this.

I’ve tested it the same way I originally noticed the issue: multiple Codex sessions open and mostly idle in the background, then watching behavior over time in normal use.

After switching over to the latest alpha build, I’m not seeing the previous per-instance log churn anymore while idle. It looks fixed from my Linux side.

I’ll keep running this build day-to-day for now and report back if I see anything regress.

I'm runnning 0.99.0-alpha.11 and do not see this error anymore.
I was running 0.101 and I don't think the issue was there anymore. There are other issues introduced into the extension and/or Codex last week which may be obscuring the results.

Just in case, this is from the output log:

2026-02-16 10:29:31.959 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.033 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.084 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.103 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.185 [info] Skills/list request cwdsCount={} forceReload={} templateArgs=[1,false]
2026-02-16 10:29:32.186 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.186 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.206 [info] Skills/list ok entries={} templateArgs=[1]
2026-02-16 10:29:32.223 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.237 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:32.300 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

[snip]

2026-02-16 10:29:34.313 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:34.313 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:34.313 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:29:34.321 [error] Error fetching {}: {} templateArgs=["vscode://codex/open-in-targets",{}]
2026-02-16 10:29:34.322 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-02-16 10:31:07.538 [error] Error fetching {}: {} templateArgs=["vscode://codex/local-environments",{}]
2026-02-16 10:31:07.538 [error] Error fetching {}: {} templateArgs=["vscode://codex/open-in-targets",{}]
2026-02-16 10:31:07.538 [error] Error fetching {}: {} templateArgs=["vscode://codex/open-in-targets",{}]
2026-02-16 10:32:00.408 [error] Error fetching {}: {} templateArgs=["vscode://codex/local-environments",{}]
2026-02-16 10:32:00.408 [error] Error fetching {}: {} templateArgs=["vscode://codex/open-in-targets",{}]
2026-02-16 10:32:00.408 [error] Error fetching {}: {} templateArgs=["vscode://codex/open-in-targets",{}]

I'll pursue the other issues separately. I'm only providing that log in case the detail is relevant here.

I thank you for your attention to this specific ticket - and to many others!!!

@TonyGravagno, yes this was addressed. Thanks for confirming the fix.