Summary
When both screenpipe.app and screenpipe - Development.app are installed on the same machine, they share the same data directory (~/.screenpipe/), the same SQLite database, and try to bind the same API port (3030). This causes the sidecar/recorder process to fail silently on one of them, leaving the UI running but with no server on 3030 — so the app appears alive but is effectively useless (search, pipes, notifications, recording all break).
Environment
macOS (Apple Silicon)
Both /Applications/screenpipe.app and /Applications/screenpipe - Development.app installed
Shared data dir: ~/.screenpipe/
Steps to reproduce
Install the production build of screenpipe.
Install the development build alongside it.
Launch both (or launch one, then the other) — or just have both auto-start at login.
Check lsof -nP -iTCP:3030 and ps aux | grep screenpipe.
Expected
Either:
The two builds use separate data directories and ports by default (e.g. dev → ~/.screenpipe-dev/ and port 3031), or
The second app to launch detects the conflict and surfaces a clear error in the UI ("port 3030 already in use by screenpipe - Development — quit it first").
Actual
One sidecar wins the port, the other dies silently.
No entry is written to ~/.screenpipe/screenpipe.YYYY-MM-DD.0.log (the recorder log file stops being created — mine has been empty since May 4 while the app log keeps spawning).
The app log only shows spawn_screenpipe: starting server + capture with no follow-up error.
Scheduled pipes start failing with "screenpipe API on port 3030 is not reachable".
The user has no indication anything is wrong until they try to search or a pipe notifies them.
Evidence from my install
$ ps aux | grep screenpipe
/Applications/screenpipe.app/Contents/MacOS/screenpipe-app
# UI alive
# no sidecar / recorder process
$ lsof -nP -iTCP:3030 -sTCP:LISTEN
# (empty — nothing listening)
$ ls -lat ~/.screenpipe/screenpipe.*.log
-rw-r--r-- 43981 May 4 15:31 screenpipe.2026-05-04.0.log # last recorder log, 16 days ago
App log shows the spawn attempt but no error:
2026-05-20T02:53:07 INFO spawn_screenpipe: starting server + capture
2026-05-20T02:53:13 WARN mdns advertisement failed (non-fatal)
# … nothing else, port never opens
Meanwhile the SQLite WAL keeps getting touched at odd times (db.sqlite-wal modified at 04:53 with no recorder running), suggesting the other build is opening the db.
Suggested fixes (any one would help)
Default to separate data dirs and ports per build flavor. The dev build should use ~/.screenpipe-dev/ and :3031 out of the box.
Detect the conflict at startup and either refuse to start with a clear modal, or auto-fall-back to a different port + data dir.
Surface sidecar spawn failures in the UI — right now a failed spawn_screenpipe is completely invisible to the user. A red banner ("recorder failed to start — see logs") would have saved me a week of confusion.
Write the recorder log earlier in startup so when it dies before logging initializes, there's still a trace of why.
Impact
For users who install both builds (anyone testing nightly / contributing), the prod app silently breaks. For users who don't realize the dev app is also auto-starting, screenpipe just appears to stop working with no error message.
Summary
When both screenpipe.app and screenpipe - Development.app are installed on the same machine, they share the same data directory (~/.screenpipe/), the same SQLite database, and try to bind the same API port (3030). This causes the sidecar/recorder process to fail silently on one of them, leaving the UI running but with no server on 3030 — so the app appears alive but is effectively useless (search, pipes, notifications, recording all break).
Environment
macOS (Apple Silicon)
Both /Applications/screenpipe.app and /Applications/screenpipe - Development.app installed
Shared data dir: ~/.screenpipe/
Steps to reproduce
Install the production build of screenpipe.
Install the development build alongside it.
Launch both (or launch one, then the other) — or just have both auto-start at login.
Check lsof -nP -iTCP:3030 and ps aux | grep screenpipe.
Expected
Either:
The two builds use separate data directories and ports by default (e.g. dev → ~/.screenpipe-dev/ and port 3031), or
The second app to launch detects the conflict and surfaces a clear error in the UI ("port 3030 already in use by screenpipe - Development — quit it first").
Actual
One sidecar wins the port, the other dies silently.
No entry is written to ~/.screenpipe/screenpipe.YYYY-MM-DD.0.log (the recorder log file stops being created — mine has been empty since May 4 while the app log keeps spawning).
The app log only shows spawn_screenpipe: starting server + capture with no follow-up error.
Scheduled pipes start failing with "screenpipe API on port 3030 is not reachable".
The user has no indication anything is wrong until they try to search or a pipe notifies them.
Evidence from my install
App log shows the spawn attempt but no error:
Meanwhile the SQLite WAL keeps getting touched at odd times (db.sqlite-wal modified at 04:53 with no recorder running), suggesting the other build is opening the db.
Suggested fixes (any one would help)
Default to separate data dirs and ports per build flavor. The dev build should use ~/.screenpipe-dev/ and :3031 out of the box.
Detect the conflict at startup and either refuse to start with a clear modal, or auto-fall-back to a different port + data dir.
Surface sidecar spawn failures in the UI — right now a failed spawn_screenpipe is completely invisible to the user. A red banner ("recorder failed to start — see logs") would have saved me a week of confusion.
Write the recorder log earlier in startup so when it dies before logging initializes, there's still a trace of why.
Impact
For users who install both builds (anyone testing nightly / contributing), the prod app silently breaks. For users who don't realize the dev app is also auto-starting, screenpipe just appears to stop working with no error message.