Question 1

Why does OpenResearch report 'The installer finished, but no working orx binary was found' on a remote SSH host?

Accepted Answer

The remote probe silently rejects any `orx` binary whose directory is group- or world-writable (including inherited group-write ACLs, e.g. mode 2775 from shared storage), so a working binary is treated as absent. The binary itself is fine — only the directory trust check fails. Fix it manually on the remote host (do not auto-modify shared directories): 1. Check permissions: `ls -ld ` and `getfacl ` 2. Remove group/other write: `chmod g-w,o-w ` (e.g. `chmod 755 ~/.local/bin` or `~/.cargo/bin`) 3. If an ACL grants group write, strip it: `setfacl -b ` (or adjust the specific entry with `setfacl -m g::r-x `) 4. Re-run the installer or refresh the host in the UI. Verify with `orx compute test ssh ` — it should report `ready: true`, `toolsFound: true`, and empty `missingTools`. If the directory is intentionally shared, keep the policy and install `orx` into a private user-owned directory instead.

Question 2

How to fix "already has an active writer" error (JSON-RPC -32600) when resuming a Codex conversation in OpenResearch on Windows?

Accepted Answer

Cause: On OpenResearch 0.2.15 for Windows with an npm-installed Codex CLI, interrupting a turn (Stop / aborted approval) can leave the native `codex.exe` app-server alive after its launcher exits. The launch chain orx.exe → cmd.exe → node.exe → codex.exe is only terminated at the direct-child level (process-group teardown is Unix-only in v0.2.15), so the orphaned native process keeps the thread-writer lock and any replacement server fails to resume with -32600 "already has an active writer". Workaround: 1) Identify the stale native process — check Task Manager for leftover `codex.exe` processes, or run `tasklist | findstr codex.exe` (a Windows Restart Manager query can confirm which PID owns the thread lock). 2) Kill only that stale process tree: `taskkill /F /PID <pid> /T`, or end it via Task Manager. Do not kill app-servers belonging to other active sessions. 3) Resume the conversation in OpenResearch — it continues with the saved permission settings, retaining existing files and history. Do NOT delete the lock file or reset the database; that is unnecessary. A permanent fix (Windows Job Object-based process-tree teardown) is pending as a follow-up to PR #484.

Question 3

Why is the OpenResearch desktop app silently spending my OpenRouter credit on expensive models, and how do I stop it?

Accepted Answer

The OpenResearch desktop AppImage spawns background opencode sessions (visible in `~/.local/share/opencode/log/opencode.log` with `directory=/tmp/.mount_OpenRe*/usr`) whose `plan` agent defaults to a paid model (`~anthropic/claude-fable-latest`) and `title` agent defaults to `gemini-nano-banana-2.1` via OpenRouter — ignoring your selected free models. Each background plan call costs ~$0.14 (11k input tokens). Workarounds until the app inherits your model selection: (1) remove the `openrouter` entry from your opencode `auth.json` so background sessions cannot reach paid models, or (2) set a hard spend/credit limit on your OpenRouter account dashboard to cap unwanted charges. Verify the source by checking the opencode log for `agent=plan` / `providerID=openrouter` entries with the AppImage mount path, and match their UTC timestamps against your OpenRouter activity page.

OpenResearch

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects