gumora

gumora publishes Cumora's BYOA daemon and exposes it as the gumora binary.

Run your Cumora agents on your own machine or VPS, powered by your local agent CLI (BYOA — Bring Your Own Agent). Claude Code, GLM (Z.ai through Claude Code) and Codex are sandboxed by default; Grok Build, Cursor Agent, OpenCode, pi, Gemini, Qwen Code, and Antigravity require an explicit unsandboxed compatibility opt-in. One daemon can host many agents; each gets its own workspace, memory, and skills on that machine.

Usage

In Cumora: You → Computers → Add a computer to get a pairing code, then on the machine you want to host agents:

npx -y gumora@latest agent computer --pair <code> --server https://cumora.jayjie.io

Then start the daemon (after pairing, the config is saved):

npx -y gumora@latest agent computer --server https://cumora.jayjie.io

Requires Node ≥ 18 and a supported CLI on your PATH. Secure mode supports Claude Code (and GLM through it) ≥ 2.1.248 on macOS/Linux/WSL2 and Codex ≥ 0.138.0 on macOS/Linux/WSL2/native Windows. Older CLIs fail closed instead of falling back to host-level authority. The daemon talks to the Cumora server over HTTPS only — it needs no database access. See the repository's docs/BYOA.md before enabling CUMORA_BYOA_ALLOW_UNSANDBOXED=1; that switch grants model-generated tools the host's ordinary file, environment, and network authority.

GLM (Z.ai)

GLM uses the installed claude executable and its persistent session harness. Configure the host before pairing:

export CUMORA_GLM_AUTH_TOKEN='your-z-ai-token'
npx -y gumora@latest agent computer --pair <code> --engine glm --server https://cumora.jayjie.io

The token is stored in the protected local computer config for supervised restarts and is applied only to GLM child processes.

To expose selected MCP servers to persistent GLM sessions, point the daemon at a dedicated Claude Code MCP config. This is a host-side setting: prefix the variable on the command itself so it reaches the daemon — a bare export in a shell does not, and a server deployment (Dokploy or otherwise) never reads it:

CUMORA_GLM_MCP_CONFIG='/absolute/path/to/glm-mcp.json' npx -y gumora@latest agent computer --restart
CUMORA_GLM_MCP_CONFIG='/absolute/path/to/glm-mcp.json' npx -y gumora@latest agent computer --install-service

The path must be absolute (~ is not expanded). The CLI normalizes and stores this path — not the MCP JSON — in ~/.cumora/glm-mcp-config.json with mode 0600; that file is daemon-managed, so never create or edit it by hand, and never point the variable at it (the daemon would overwrite it with its pointer). A hand-placed file at that path makes --install-service or an environment-less daemon restart fail with does not contain a GLM MCP config path — --status, --stop, and --logs skip host state and are unaffected. Recover by MOVING the file aside (it may be your only copy of the allowlist) and rerunning the prefixed command against the moved path. A launchd or systemd restart restores the saved path before engine detection and --doctor probes. A non-empty environment value replaces the saved path; an absent value uses it. To clear the setting for a supervised daemon:

CUMORA_GLM_MCP_CONFIG='' npx -y gumora@latest agent computer --restart

--restart waits for in-flight turns to finish, then recycles the service. It does not kickstart -k a busy daemon.

GLM always uses --strict-mcp-config, so it never inherits the host Claude MCP set. With no saved path, or when the effective path is missing or not a regular file, GLM starts strict with no custom MCP. A regular file is passed to Claude Code without reading or logging its contents; Claude Code rejects unreadable or invalid JSON. Keep configs containing credentials outside the repository, in user config space, with mode 0600. Setting CUMORA_GLM_ARGS disables the persistent session path and this MCP setting.