Skip to main content
The FileWatcher and FileChangeHandler utilities provide file system monitoring for GAIA agents. Use them to watch directories for changes and trigger callbacks when files are created, modified, deleted, or moved.

Quick Start

Two Approaches

Use FileWatcher for simple directory watching with automatic lifecycle management:

2. FileChangeHandler (Advanced)

Use FileChangeHandler directly when you need more control:

Integration with Agents

FileWatcher works seamlessly with GAIA agents:

API Reference

FileWatcher

Methods

FileChangeHandler

Examples

Watch All Files

Custom Filter

Handle Moves/Renames

Access Telemetry

Default Extensions

When extensions is not specified, FileChangeHandler watches these file types:
  • Documents: .pdf, .txt, .md, .markdown, .rst
  • Data: .csv, .json, .xml, .yaml, .yml
  • Code: .py, .js, .ts, .java, .cpp, .c
  • Web: .html, .css
  • Logs: .log

Best Practices

Files Are Reported Once They Settle

A created or modified file is reported once it has gone debounce_seconds with no events and no change in size or modification time, so a file still being copied in is never read half-written, and a burst of saves becomes one callback. A file that never stops changing, such as a log that is written to constantly, is not reported until it pauses. Deletes and moves are reported as they arrive. A delete event for a path that still exists (macOS reports a file replaced by rename this way) is reported as a modification instead, or as a creation when only on_created is set; with neither set, it is dropped.

Handle Errors in Callbacks

Callbacks run on the watcher’s own dispatch thread, one at a time, so a slow callback does not hold up event delivery. An exception a callback raises is logged with its traceback, and the next event is still delivered. Let PermissionError propagate. On Windows, a file another program holds for exclusive access, or has a byte-range lock on, fails to read with PermissionError. When an on_created or on_modified callback raises it, the watcher reports the file again after 1, 2 and 4 windows. When an on_moved callback raises it, the destination is reported again the same way, as a modification, because editors save by renaming a temp file onto the document. If the file is still locked after the last retry, the watcher logs one error, with the traceback, telling the user to close the program and save the file again. A callback that catches PermissionError, for example with a bare except Exception, turns that retry off, and a file that was briefly locked is never processed. On Linux and macOS a read is never blocked by another program, so a PermissionError there means the file’s permissions forbid it; the watcher retries it the same way and then gives up.

Clean Up Resources

Always stop the watcher when done:

Requirements

FileWatcher requires the watchdog package:
Check if watchdog is available:

Complete Example

A complete working agent that watches a directory and tracks processed files using FileWatcherMixin:
Usage: