Systemprompt Internal

Systemprompt Internal — AI business management on Odoo. Odoo is the system of record; this platform is the AI and communication layer. One self-hosted binary governs inference, auditing, and every tool call across your AI fleet. Any agent, any model, any provider.

systemprompt.io · Platform documentation · Guides · Discord

---

Setup

From nothing to Claude Code running against your own governed gateway.

1. Prerequisites

Requirement	Why	Install
Rust 1.94+	Compiles the binary	rustup.rs
Docker	Runs PostgreSQL 18	docs.docker.com
just	Task runner — every command below	just.systems
jq, yq	Used by the setup scripts	apt install jq yq / brew install jq yq
An AI API key	Anthropic, OpenAI, or Gemini — one is enough	Provider dashboard

Ports 8080 (HTTP) and 5432 (Postgres) must be free.

2. Clone

git clone https://github.com/systempromptio/systemprompt-internal
cd systemprompt-internal

The server needs this repository alone: the workspace resolves systemprompt from crates.io, and the [patch.crates-io] blocks in Cargo.toml and tests/Cargo.toml are commented out. Uncomment both — [patch] is per-workspace — to build the server against a sibling core checkout while a core change is unreleased.

The client is different. bridge/ depends on systemprompt-bridge by relative path, and that crate is not published, so building it requires systemprompt-core checked out beside this repository. just bridge-build clones it for you; nothing else needs it.

3. Set up and start

just setup-local     # builds the binary, writes .systemprompt/profiles/local/,
                     # starts Docker Postgres, runs the publish pipeline
just bridge-build    # builds the Claude Code client; clones systemprompt-core
                     # beside this repo, which the client depends on by path
just start           # governance + agents + MCP + admin on :8080

bridge-build is part of setup rather than part of connecting: connect codes expire in ten minutes, and a first client build takes longer than that.

setup-local prompts for your provider and its key. Non-interactive instead — the first key given becomes the default provider:

just setup-local <anthropic_key> [openai_key] [gemini_key]

Defaults are 8080 and 5432. A second clone on the same host overrides both: just setup-local <key> "" "" 8081 5436.

4. Connect Claude Code

Create an account at http://localhost:8080/admin/login — registration is passkey-based and gated on the configured email domain; there is no password. The code is bound to the signed-in identity, so this comes first.

Then open /admin/profile and copy the connect code:

just claude <code>

A new account has user permissions. Admin-only pages, the systemprompt MCP server, and the admin plugins stay hidden until it is promoted:

systemprompt admin users role promote <email>

Sign out and back in afterwards — the admin scope is minted when the token is issued, so an existing session keeps the old one.

Starts a container, redeems the code, execs claude. Host config is untouched: no installer runs, ~/.claude and ~/.config are not written.

A code is needed the first time only. The credential it is exchanged for persists, so afterwards the command is just just claude.

The container and its home are scoped to the clone and the gateway (systemprompt-claude-<repo>-<hash>-<gateway>), so several checkouts pointing at different gateways coexist and never inherit each other's credential. just claude-reset signs this clone out; just claude-reset ALL=1 signs out every clone on the host.

Every request lands in the audit table with user, session, trace, tokens, and cost.

Codes are 32 random bytes, stored hashed, 10-minute TTL, single use. The client redeems one for a durable PAT held on the machine it was issued to. systemprompt admin bridge issue-code --user-id <email> issues the same code without a browser.

To configure the host instead of a container: just connect <code>. That writes ~/.config/systemprompt-internal/, a managed block in ~/.profile, ~/.claude/managed-settings.json, ~/.local/share/Claude/org-plugins/, and two systemd user units.

Verifying from a clean state

Run after any change to the connect path. The failure mode is silent — a machine holding a valid credential skips sign-in and still exits 0.

This section runs on 8081/5436 rather than the 8080/5432 defaults, so the test instance coexists with a gateway already running. Substitute the defaults if nothing else is up.

git clone https://github.com/systempromptio/systemprompt-internal fresh && cd fresh
just setup-local <provider-key> "" "" 8081 5436   # ports of its own
just build
just bridge-build
just start

The database has no users. Either register at http://localhost:8081/admin/login and take the code from the profile page, or stay headless — both write the same bridge_exchange_codes row:

systemprompt admin users create --name you --email you@example.com --if-not-exists
systemprompt admin users role promote you@example.com
systemprompt admin bridge issue-code --user-id you@example.com

claude-reset is load-bearing — without it a surviving credential carries the test:

just claude-reset
just claude <code> http://localhost:8081

Assert on the output, not the exit code. Pass: signing in with the supplied code. Fail: already signed in — reusing the stored PAT — sign-in never ran.

systemprompt-internal-bridge doctor runs last, one line per check. The hook-token warning is expected: OAuth client provisioning is lazy, on first plugin hook request, not during sync.

5. Day-to-day

just build            # debug build (--release for release)
just preflight        # the CI gate: static → lint → tests → coverage
just publish          # rebuild templates, CSS, JS, assets
systemprompt --help   # discover the CLI

Upgrading core

Two ways to depend on systemprompt-core, chosen by the [patch.crates-io] blocks in Cargo.toml and tests/Cargo.toml:

# Published release from crates.io — patch blocks commented out.
just core-bump X.Y.Z

# Local sibling checkout, for a core change that is not released yet —
# patch blocks uncommented in BOTH manifests, pins set to the core version.
just build && just prepare && just verify

Either way the core version in both manifests must match the version you are building against; a mismatch drops the patch silently. Core ships its own migrations, so run the new binary once against your database. Details and the release procedure: docs/RELEASING.md.

---

       

_{Own how your organization uses AI. Every interaction governed and provable.}