afterFileEdit hook not firing reliably, missing events on batch edits and mid-session

Support Bug Reports
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Summary

The afterFileEdit hook fires inconsistently. We’ve observed two distinct failure patterns across multiple conversations where the agent edited files but the hook was never triggered.

Pattern 1: Batch edits in a single agent turn

When the agent edits multiple files in one turn, afterFileEdit fires for the first file only. Subsequent edits in the same turn produce no hook event, even though the edits are confirmed in the agent’s output.

Example timeline (timestamps approximate, UTC):

19:03:30 Agent edits file 1 → afterFileEdit fires ✓
19:03:31 Agent edits file 2 → afterFileEdit silent ✗
19:03:31 Agent edits file 3 → afterFileEdit silent ✗
19:03:31 Agent edits file 4 → afterFileEdit silent ✗
19:03:31 Agent edits file 5 → afterFileEdit silent ✗

All 5 edits are confirmed — we can see the surrounding hook events (preToolUse, postToolUse) arrive for each file. Only afterFileEdit is missing for files 2–5.

Pattern 2: Hook goes silent mid-session then recovers

In a longer session, afterFileEdit fires normally, then goes completely silent for an extended period (3–4 hours of active editing across many files), then spontaneously recovers and fires correctly again for the remainder of the session —
with no restart or configuration change.

Example timeline:

~13:30 Multiple file edits → afterFileEdit fires correctly ✓
~14:00 Multiple file edits → afterFileEdit fires correctly ✓
~19:03 Batch of 5 file edits → afterFileEdit fires for first file only ✗
– next day –
~21:18 File edits → afterFileEdit fires correctly ✓
– two days later –
~12:15 File edits → afterFileEdit silent for ~4 hours ✗
~12:36 File edits (multiple) → afterFileEdit silent ✗
~15:13 File edits → afterFileEdit silent ✗
~16:51 File edits → afterFileEdit fires correctly again ✓ ← recovery
~16:58 File edits → afterFileEdit fires correctly ✓

The recovery at 16:51 coincided with the user referencing a specific file in the prompt (@filename:line), though it’s unclear if that’s causal.

What we’ve verified

  • The edits definitely happened — the agent’s output confirms the files were modified
  • Other hooks (preToolUse, postToolUse, beforeSubmitPrompt) fire reliably throughout the same sessions, including during the silent gaps
  • The silence is specific to afterFileEdit
  • Restarting was not required for recovery in Pattern 2 — the hook resumed on its own

Environment

  • Hook type: afterFileEdit
  • Agent mode (agentic, multi-file editing)
  • Observed across multiple users and multiple sessions

Happy to provide agent transcript excerpts or additional details if useful for debugging.

Steps to Reproduce

We have not been able to reliably reproduce either pattern on demand. Both appear intermittent.

For Pattern 1 (most likely to reproduce):

  1. Start an agentic session
  2. Give the agent a prompt that causes it to edit multiple files in a single turn (e.g. “implement X across these files”)
  3. Observe whether afterFileEdit fires for all edited files or only the first

For Pattern 2:
We have no reliable trigger. It was observed in long-running sessions (3+ hours, 100+ agent turns) and resolved without any explicit action.

We’d be happy to share sanitised agent transcripts from the affected sessions if that helps narrow down a reproduction case.

Expected Behavior

afterFileEdit should fire once for every file the agent edits, regardless of:

  • How many files are edited in a single agent turn
  • How long the session has been running
  • Whether the edit is to an existing file or a newly created file

The hook behaviour should be consistent with preToolUse and postToolUse, which fire reliably for every tool call throughout the session.

Operating System

MacOS

Version Information

Cursor: 2.6.21 (Universal), Stable, Default track
VS Code: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Build: 2026-03-21
OS: Darwin arm64 25.2.0

For AI issues: add Request ID with privacy disabled

Here are a couple of conversation IDs we debugged that reproduce both patterns described above:

  • 2316d089-bf6b-4b56-81ff-a89eb27c63b7
  • 561b1482-6026-4879-9d52-1f11075b3700

Additional Information

We instrument Cursor’s hooks for internal analytics and noticed the gaps in afterFileEdit events while reviewing our data. We’re happy to share sanitised hook event logs from these sessions if useful.

A few specific questions that would help us understand the issue:

  • Is afterFileEdit documented to fire only once per agent turn rather than once per file when multiple files are edited in a single turn?
  • Is there a known condition under which the hook can enter a silent state mid-session?
  • Does referencing a file explicitly in a prompt (e.g. @filename:line) have any effect on hook dispatch?

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi @PankajS,

Thanks for the thorough report. The timeline data and the observation that preToolUse/postToolUse continue working while afterFileEdit goes silent is exactly the kind of evidence that helps us narrow this down.

Confirmed, this is a bug. afterFileEdit should fire once per file edit, regardless of how many files are edited in a single turn.

To answer your questions:

  • Is afterFileEdit documented to fire once per turn or once per file? Once per file. Your expectation is correct.

  • Is there a known condition for the hook going silent mid-session? Not a documented condition. Your report is helping us identify potential issues in how hook dispatch state is maintained during long sessions.

  • Does referencing @filename affect hook dispatch? Not directly, but it can trigger workspace state activity that may indirectly cause the hook system to re-evaluate its configuration.

I’ve passed this to our team. If you have the sanitised hook event logs from those sessions, they would be helpful for the engineering investigation. The gap between other hooks firing and afterFileEdit going silent is a strong diagnostic signal.

I’ll get back to you once I have more updates on this.

8

@PankajS - One more thing – could you check the Hooks Execution Logs in Cursor? You can find them at Cursor Settings > Hooks > Execution Logs.

These logs capture every hook execution from Cursor’s side, including afterFileEdit. If the execution logs also show gaps matching what your analytics system is seeing, that confirms the issue is in Cursor’s hook dispatch. If the logs show the hooks fired but your system didn’t receive the events, it would point to something in the hook script or the receiving end.

Next time the issue occurs, a screenshot or export of the execution logs around the affected time window would be very helpful for the engineering investigation.

9

Thank you @mohitjain! I’ll get back to you with the logs. Couple of questions

  1. Looks like the execution logs are different per conversation so would you recommend opening the particular chat where we say issues?
  2. Also is there a file that we can check for execution logs? In the Cursor app it seemed the logs were truncated so if there is a metadata file which we can look up for complete logs that will be amazing.
10

1. Per-conversation or global?
The execution logs are global for the entire Cursor window, not per-conversation. All hook executions across all your chats are captured in the same log. So you don’t need to open a specific chat. However, the log only keeps the last 100 entries, so check it soon after the issue occurs to catch the relevant entries before newer ones push them out.

2. Complete logs on disk? Yes. The in-app execution log (Cursor Settings > Hooks) is capped at 100 entries, which is likely why it looked truncated. But there’s a complementary log that writes to disk without that cap:

  • Open View > Output, then select Hooks from the dropdown at the top right. This output channel logs the same hook executions in full.

  • The underlying file is at: ~/Library/Application Support/Cursor/logs/<session>/window<N>/output_<timestamp>/cursor.hooks.log

  • You can also open the logs folder directly via Command Palette > Developer: Open Logs Folder, then look for the output_*/cursor.hooks.log file in that directory.

For the best diagnostic data, next time the issue occurs: grab the cursor.hooks.log file from the current session’s log directory. That will have the complete, un-truncated hook execution history for the window.

11

Thank you @mohitjain ! This is really useful information. Appreciate your help!!

Seems the logs are old so some of them have been pruned. But I’m going to keep this mind and check for more examples this week.

1 Like