Upgrade StorageFeature Request: Headless/daemon mode for agent and automation access
I'd like to request a headless or daemon mode for Zotero — the ability to run Zotero's local API server without requiring the GUI application to be open and visible.
Current situation:
The local API (port 23119) introduced in Zotero 7 is a **fantastic** addition — it exposes the web API locally, which means my local tools can interact with the local database without going through zotero.org. However, this API is only available when the Zotero desktop application is running with a full GUI session.
For those of us using Zotero on servers, headless Linux machines, or in automation/agent workflows, this creates a fundamental gap: you must have an active display (real or virtual via xvfb) just to keep the local API server alive. Team members have noted "something along those lines is planned, but no ETA."
I work with AI agents that interact with my Zotero library programmatically. My workflow involves:
- Automated retrieval — agents query the local API to search for items, pull metadata, retrieve PDFs, and follow citation chains, all without manual intervention
- Scheduled operations — cron jobs and background processes sync, validate, and enrich library data on a schedule
- Server deployment — the Zotero instance lives on a headless Linux server that has no display and no one sitting at a keyboard
Right now, the only option is to run Zotero inside xvfb and hope it stays up, or use the web API which doesn't provide access to my local/webdav attachments.
AI agents need structured access to reference databases, this use case is only going to grow. Projects like zotero-headless (a community-built clean-room runtime) prove there's real demand for headless Zotero access — but a community reimplementation shouldn't be the only path.
What I'm requesting:
A --headless or --daemon flag (or equivalent) that:
1. Starts Zotero's core services (database, sync, local API server) without initializing the GUI
2. Makes the local API on port 23119 available just as it is when the full app runs
3. Can be run on a server, in a container, or as a systemd service
4. Doesn't require xvfb, a display server, or any active desktop session. CLI only.
The local API code already exists in Zotero's source (chrome/content/zotero/xpcom/server/server_localAPI.js). The Zotero.init() entrypoint and commandLineHandler.js already support flags like --datadir. A --headless flag that skips the UI initialization and just starts the database + HTTP server seems architecturally feasible — the zotero-headless project's source notes even identify commandLineHandler.js as "a natural seam for a dedicated ZoteroDaemon bootstrap flag."
Why this helps the ecosystem:
- AI/agent integration — agents can query and manage reference libraries natively without fragile xvfb workarounds
- Server deployments — universities, labs, and research groups can run Zotero as a persistent service
- Backup automation — scheduled syncs and library exports don't need a logged-in desktop session
- CI/CD — automated tests and pipelines can validate citation data without GUI overhead
- Local API write support — the existing local API is still read-only; a headless mode would be a natural reason to extend the API to enable writes (the versioning work in #5011 and #5015 is already progressing this).
I recognize this is a significant architectural request, and I'm happy to discuss scope. Even a minimal headless mode (database + read-only local API, no sync) would be transformative for agential and automation workflows.
Thank you for considering this.
Current situation:
The local API (port 23119) introduced in Zotero 7 is a **fantastic** addition — it exposes the web API locally, which means my local tools can interact with the local database without going through zotero.org. However, this API is only available when the Zotero desktop application is running with a full GUI session.
For those of us using Zotero on servers, headless Linux machines, or in automation/agent workflows, this creates a fundamental gap: you must have an active display (real or virtual via xvfb) just to keep the local API server alive. Team members have noted "something along those lines is planned, but no ETA."
I work with AI agents that interact with my Zotero library programmatically. My workflow involves:
- Automated retrieval — agents query the local API to search for items, pull metadata, retrieve PDFs, and follow citation chains, all without manual intervention
- Scheduled operations — cron jobs and background processes sync, validate, and enrich library data on a schedule
- Server deployment — the Zotero instance lives on a headless Linux server that has no display and no one sitting at a keyboard
Right now, the only option is to run Zotero inside xvfb and hope it stays up, or use the web API which doesn't provide access to my local/webdav attachments.
AI agents need structured access to reference databases, this use case is only going to grow. Projects like zotero-headless (a community-built clean-room runtime) prove there's real demand for headless Zotero access — but a community reimplementation shouldn't be the only path.
What I'm requesting:
A --headless or --daemon flag (or equivalent) that:
1. Starts Zotero's core services (database, sync, local API server) without initializing the GUI
2. Makes the local API on port 23119 available just as it is when the full app runs
3. Can be run on a server, in a container, or as a systemd service
4. Doesn't require xvfb, a display server, or any active desktop session. CLI only.
The local API code already exists in Zotero's source (chrome/content/zotero/xpcom/server/server_localAPI.js). The Zotero.init() entrypoint and commandLineHandler.js already support flags like --datadir. A --headless flag that skips the UI initialization and just starts the database + HTTP server seems architecturally feasible — the zotero-headless project's source notes even identify commandLineHandler.js as "a natural seam for a dedicated ZoteroDaemon bootstrap flag."
Why this helps the ecosystem:
- AI/agent integration — agents can query and manage reference libraries natively without fragile xvfb workarounds
- Server deployments — universities, labs, and research groups can run Zotero as a persistent service
- Backup automation — scheduled syncs and library exports don't need a logged-in desktop session
- CI/CD — automated tests and pipelines can validate citation data without GUI overhead
- Local API write support — the existing local API is still read-only; a headless mode would be a natural reason to extend the API to enable writes (the versioning work in #5011 and #5015 is already progressing this).
I recognize this is a significant architectural request, and I'm happy to discuss scope. Even a minimal headless mode (database + read-only local API, no sync) would be transformative for agential and automation workflows.
Thank you for considering this.