Skip to content

Abusive Skills/list polling #10831

Closed
Closed
Abusive Skills/list polling#10831
Labels
bugSomething isn't workingextensionIssues related to the VS Code extensionwindows-osIssues related to Codex on Windows systems

Description

@TonyGravagno
TonyGravagno
opened on Feb 6, 2026

What version of the IDE extension are you using?

0.4.71

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

VSCode output window for Codex extension shows permanent loop resulting in this output:

2026-02-05 16:32:17.098 [info] Skills/list ok entries=1
2026-02-05 16:32:17.098 [info] Received app server result: 2ddfe5a3-d157-46e2-a7f7-d79d2a53a18e object(keys=1)
2026-02-05 16:32:17.098 [info] Skills/list ok entries=1
2026-02-05 16:32:18.068 [info] Skills/list request cwdsCount=1 forceReload=false
2026-02-05 16:32:18.068 [info] Skills/list request cwdsCount=1 forceReload=false
2026-02-05 16:32:18.120 [info] Received app server result: 8ff89d74-039b-4ac0-bb8f-e54fae7afdf0 object(keys=1)
2026-02-05 16:32:18.120 [info] Skills/list ok entries=1
2026-02-05 16:32:18.120 [info] Received app server result: 8300146b-6f49-4091-a7f2-f7d81c027523 object(keys=1)
2026-02-05 16:32:18.120 [info] Skills/list ok entries=1
2026-02-05 16:32:19.076 [info] Skills/list request cwdsCount=1 forceReload=false

This may be a consequence of #10478 which was just added today.
I have no additional skills defined. There's nothing to find and I'd like to disable this polling.

Running in Windows 11 "remote" to local WSL2.

What steps can reproduce the bug?

Run a Codex query. Watch the output window. When it finishes the polling continues even though there's no active query.
Restart VSCode (reload window) ... the output window is silent after loading.
Open the Codex panel, polling restarts.
Close the Codex panel, polling continues.

Image

What is the expected behavior?

At end of query when results are provided, stop polling for skills.
On opening Codex panel, don't poll for skills until query starts.
Do not attempt to read for skills outside the scope of an active query.
Apply the documented behavior: pre-load skill descriptions and don't check for skills unless needed. This should include only checking to see if skills have been manipulated during this active time.

Additional information

Might not be related to new polling at all. I never looked at the window before and I have not downgraded to see if this issue existed before.

Activity

  1. TonyGravagno
    added
    extensionIssues related to the VS Code extension
    on Feb 6, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    on Feb 6, 2026

  3. Neuro-Dynamics commented on Feb 6, 2026

    @Neuro-Dynamics
    Neuro-Dynamics
    on Feb 6, 2026

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

  4. etraut-openai commented on Feb 6, 2026

    @etraut-openai
    etraut-openai
    on Feb 6, 2026
    Contributor

    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.

  5. etraut-openai commented on Feb 6, 2026

    @etraut-openai
    etraut-openai
    on Feb 6, 2026
    Contributor

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

  6. GitHubJKin commented on Feb 6, 2026

    @GitHubJKin
    GitHubJKin
    on Feb 6, 2026

    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
    Image

  7. Neuro-Dynamics commented on Feb 6, 2026

    @Neuro-Dynamics
    Neuro-Dynamics
    on Feb 6, 2026

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

    WSL

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

  8. Neuro-Dynamics commented on Feb 6, 2026

    @Neuro-Dynamics
    Neuro-Dynamics
    on Feb 6, 2026

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

  9. GraciousGazelles commented on Feb 8, 2026

    @GraciousGazelles
    GraciousGazelles
    on Feb 8, 2026

    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:

    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.

  10. etraut-openai commented on Feb 8, 2026

    @etraut-openai
    etraut-openai
    on Feb 8, 2026
    Contributor

    @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?

  11. GraciousGazelles commented on Feb 9, 2026

    @GraciousGazelles
    GraciousGazelles
    on Feb 9, 2026

    @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.

  12. TonyGravagno commented on Feb 9, 2026

    @TonyGravagno
    TonyGravagno
    on Feb 9, 2026
    Author

    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!

  13. etraut-openai commented on Feb 9, 2026

    @etraut-openai
    etraut-openai
    on Feb 9, 2026
    Contributor

    @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.

  14. GraciousGazelles commented on Feb 11, 2026

    @GraciousGazelles
    GraciousGazelles
    on Feb 11, 2026

    @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.

  15. TonyGravagno commented on Feb 16, 2026

    @TonyGravagno
    TonyGravagno
    on Feb 16, 2026
    Author

    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!!!

  16. etraut-openai commented on Feb 16, 2026

    @etraut-openai
    etraut-openai
    on Feb 16, 2026
    Contributor

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

  17. etraut-openai
    closed this as completedon Feb 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingextensionIssues related to the VS Code extensionwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions