Omni Code Desktop 1.8.1 on Windows (10/11).
Repro + what fixed it (high signal):
Symptom: App stuck on “Connecting…” / never finishes loading chat UI.
I tried clearing %APPDATA%\Omni Code (Electron userData / expected app folder) and resetting launcher settings, but the issue persisted.
Fix: deleting %APPDATA%\OmniCode (no space) and %USERPROFILE%.omniagents resolved it immediately (startup returned list_sessions → result=[] and the app loaded normally).
This strongly suggests backend state was stored in a different location than the launcher reset/cleanup targets.
Summary:
On Windows, the Electron app’s userData path is %APPDATA%\Omni Code (space) but the Python backend uses %APPDATA%\OmniCode (no space). This splits state across two locations, causing “reset/cleanup” actions to miss the real backend DB/session data. In addition, very large sessions can cause the UI to appear stuck on “Connecting…”, and the CLI wrapper always injects --mode ink which can conflict with launcher-provided --mode web.
Windows path mismatch (root cause of “ghost sessions” / reset misses real DB)
Electron app uses productName: "Omni Code" so Electron app.getPath('userData') resolves under %APPDATA%\Omni Code....
Backend config uses PROJECT_NAME_WINDOWS = "OmniCode" and stores config/state under %APPDATA%\OmniCode.
Result: sessions/config/db can persist even after deleting %APPDATA%\Omni Code, making it look like the app can’t be reset.
How to Reproduce:
Use Omni Code and create chat sessions.
Attempt a “reset/cleanup” by deleting %APPDATA%\Omni Code (or any UI reset that only affects Electron store/userData).
Relaunch: sessions/state still present because backend data is in %APPDATA%\OmniCode.
Expected:
Reset/cleanup should remove the backend’s persistent DB/sessions/config OR backend should store under the same root as the launcher’s userData.
Actual:
Backend state survives because it’s stored in a different folder than what users naturally clear.
Suggested Fix:
Make backend config directory overridable via env var (recommended):
Example: OMNI_CONFIG_DIR or OMNI_USER_DATA passed from Electron via child_process.spawn(..., env).
Backend get_config_dir() should use the override if set; otherwise default.
Or rename backend default on Windows from OmniCode to Omni Code (breaking change unless migration is added).
Relevant Code:
Desktop repo: src/main/util.ts currently hardcodes config dir to match backend convention:
getOmniConfigDir() → %APPDATA%/OmniCode
Backend installed code (Python):
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omni_code\config.py
PROJECT_NAME_WINDOWS = "OmniCode"
get_config_dir() returns %APPDATA%/OmniCode
“Connecting…” hang on large sessions (startup pain) Symptoms:
App appears permanently stuck on “Connecting…” / “Loading interface” with no obvious frontend console error.
Trigger observed when a chat session grows very large (hundreds of messages).
Likely Cause:
The web UI requests session history and processes it synchronously into UI state.
Large histories mean large JSON payload + heavy JS processing, which can stall UI responsiveness.
Suggested Fix:
Ensure startup only loads session metadata; load message history lazily and/or paginate:
list_sessions should return metadata only (id, timestamps, message_count, maybe first/last message excerpt).
get_session_history should support pagination (limit/offset or cursor) and UI should incrementally load.
Relevant Code:
Backend session listing returns metadata (includes message_count + first/last message):
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omniagents\core\session\history_db.py
list_sessions() returns metadata + first/last message
Full history load happens via:
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omniagents\core\agents\service.py
get_session_history() returns full filtered history
Web UI consumes full history in one shot:
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omniagents\backends\web\ui\src\App.tsx
handleSelectSession() calls client.getSessionHistory(id) and loops entire history to build items
CLI mode argument conflict (--mode ink injected) Symptoms:
Backend can exit immediately or behave incorrectly if conflicting --mode values are present (e.g., launcher passes --mode web but wrapper injected --mode ink first).
Root Cause:
The omni console entrypoint prepends --mode ink unconditionally then appends launcher args:
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\main.py
new_args = ["omniagents", "run", "--project", ..., "--mode", "ink"]
new_args.extend(args)
Suggested Fix:
Do not force --mode ink when a mode is explicitly provided, or set a default only if no --mode appears in args.
Impact:
Users cannot reliably reset state on Windows.
Large sessions can make the app appear broken/hung.
Mode conflicts can cause silent backend exits.
Omni Code Desktop 1.8.1 on Windows (10/11).
Repro + what fixed it (high signal):
Symptom: App stuck on “Connecting…” / never finishes loading chat UI.
I tried clearing %APPDATA%\Omni Code (Electron userData / expected app folder) and resetting launcher settings, but the issue persisted.
Fix: deleting %APPDATA%\OmniCode (no space) and %USERPROFILE%.omniagents resolved it immediately (startup returned list_sessions → result=[] and the app loaded normally).
This strongly suggests backend state was stored in a different location than the launcher reset/cleanup targets.
Summary:
On Windows, the Electron app’s userData path is %APPDATA%\Omni Code (space) but the Python backend uses %APPDATA%\OmniCode (no space). This splits state across two locations, causing “reset/cleanup” actions to miss the real backend DB/session data. In addition, very large sessions can cause the UI to appear stuck on “Connecting…”, and the CLI wrapper always injects --mode ink which can conflict with launcher-provided --mode web.
Windows path mismatch (root cause of “ghost sessions” / reset misses real DB)
Electron app uses productName: "Omni Code" so Electron app.getPath('userData') resolves under %APPDATA%\Omni Code....
Backend config uses PROJECT_NAME_WINDOWS = "OmniCode" and stores config/state under %APPDATA%\OmniCode.
Result: sessions/config/db can persist even after deleting %APPDATA%\Omni Code, making it look like the app can’t be reset.
How to Reproduce:
Use Omni Code and create chat sessions.
Attempt a “reset/cleanup” by deleting %APPDATA%\Omni Code (or any UI reset that only affects Electron store/userData).
Relaunch: sessions/state still present because backend data is in %APPDATA%\OmniCode.
Expected:
Reset/cleanup should remove the backend’s persistent DB/sessions/config OR backend should store under the same root as the launcher’s userData.
Actual:
Backend state survives because it’s stored in a different folder than what users naturally clear.
Suggested Fix:
Make backend config directory overridable via env var (recommended):
Example: OMNI_CONFIG_DIR or OMNI_USER_DATA passed from Electron via child_process.spawn(..., env).
Backend get_config_dir() should use the override if set; otherwise default.
Or rename backend default on Windows from OmniCode to Omni Code (breaking change unless migration is added).
Relevant Code:
Desktop repo: src/main/util.ts currently hardcodes config dir to match backend convention:
getOmniConfigDir() → %APPDATA%/OmniCode
Backend installed code (Python):
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omni_code\config.py
PROJECT_NAME_WINDOWS = "OmniCode"
get_config_dir() returns %APPDATA%/OmniCode
“Connecting…” hang on large sessions (startup pain) Symptoms:
App appears permanently stuck on “Connecting…” / “Loading interface” with no obvious frontend console error.
Trigger observed when a chat session grows very large (hundreds of messages).
Likely Cause:
The web UI requests session history and processes it synchronously into UI state.
Large histories mean large JSON payload + heavy JS processing, which can stall UI responsiveness.
Suggested Fix:
Ensure startup only loads session metadata; load message history lazily and/or paginate:
list_sessions should return metadata only (id, timestamps, message_count, maybe first/last message excerpt).
get_session_history should support pagination (limit/offset or cursor) and UI should incrementally load.
Relevant Code:
Backend session listing returns metadata (includes message_count + first/last message):
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omniagents\core\session\history_db.py
list_sessions() returns metadata + first/last message
Full history load happens via:
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omniagents\core\agents\service.py
get_session_history() returns full filtered history
Web UI consumes full history in one shot:
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\omniagents\backends\web\ui\src\App.tsx
handleSelectSession() calls client.getSessionHistory(id) and loops entire history to build items
CLI mode argument conflict (--mode ink injected) Symptoms:
Backend can exit immediately or behave incorrectly if conflicting --mode values are present (e.g., launcher passes --mode web but wrapper injected --mode ink first).
Root Cause:
The omni console entrypoint prepends --mode ink unconditionally then appends launcher args:
%APPDATA%\Omni Code\omni.venv\Lib\site-packages\main.py
new_args = ["omniagents", "run", "--project", ..., "--mode", "ink"]
new_args.extend(args)
Suggested Fix:
Do not force --mode ink when a mode is explicitly provided, or set a default only if no --mode appears in args.
Impact:
Users cannot reliably reset state on Windows.
Large sessions can make the app appear broken/hung.
Mode conflicts can cause silent backend exits.