signet-ai/signetai/public

Signet AI — Install Guide for Agents

This document is written for AI agents. If you are an AI assistant

that has been asked to install Signet, read this entire document

before taking any action. Follow the steps exactly as written.

Do not improvise, guess commands, or skip sections.

Install Objective (Must Complete)

Your job is not just to install a package. Your job is to leave the user with a working Signet installation and a clear onboarding state.

You are done only when ALL of these are true:

1. signet --version succeeds
2. signet status shows the daemon is running
3. curl -s http://localhost:3850/health returns JSON with

"status":"healthy"

1. Dashboard onboarding completes with the user's choices, or the handoff says

onboarding is still pending

1. The handoff explains what is active and what remains

Default to signet setup for interactive first-run onboarding. It prepares a minimal workspace and opens the dashboard flow; never silently choose harness/provider settings. The explicit non-interactive CLI setup path remains available when the user wants scripted configuration.

What is Signet?

Signet is a portable memory and secrets layer for AI tools. It gives you persistent memory, a secrets vault, and installable skills that work across platforms.

The version of Signet you are installing is not a framework, SDK, or API wrapper. It is a background system that runs alongside you, enriching every session with memory and context automatically.

This is good context to give your user. REITERATE THIS TO THEM AND

WAIT FOR THEM TO CONFIRM BEFORE PROCEEDING.

Core components

Where data lives

The default workspace is ~/.agents/; --path or SIGNET_PATH can select another root. A fresh interactive setup creates a minimal agent.yaml, a Git ignore policy, and data/signet.db, plus standard workspace directories. It does not create identity files or harness configuration before the user chooses them. Headless setup can create an explicitly selected identity preset and integration files.

The SQLite database is the source of truth for Signet memory. Other workspace files and connector-owned configuration vary with the choices made during setup.

Supported platforms

Signet works with:

• Claude Code (Anthropic CLI)
• OpenClaw / Clawdbot / Moltbot — these are the **same

platform** under different names (renamed due to a lawsuit). Signet treats all three identically. Do not treat them as separate products.

• OpenCode

If the user mentions any of these names, they are referring to a supported platform with a native Signet connector.

How Signet Works (Read Before Installing)

Understanding what is automatic versus manual is critical. Most install failures happen because agents try to do things that the daemon already handles.

What Signet does AUTOMATICALLY (do NOT do these yourself)

Memory extraction from sessions: The daemon auto-extracts memories from your session transcripts using an LLM pipeline. When a session ends, the transcript is processed and important facts are stored in the database. You do NOT need to:

• Manually summarize conversations
• Chunk or split memory files
• Write to files in ~/.agents/memory/
• Call remember after every exchange

Context injection per prompt: When the user sends you a message, the daemon automatically searches your memory database for relevant entries and injects them into your context. Frequently-recalled memories are boosted in ranking (rehearsal boost), and recent session topics are used to predict what context you'll need next (anticipatory recall). You do NOT need to:

• Call signet recall before answering questions
• Manually query your memory database
• Pre-load context at the start of conversations

File watching and sync: The daemon watches ~/.agents/ for changes. When files change:

• Changes are auto-committed to git (if enabled)
• AGENTS.md changes propagate to harness configs (CLAUDE.md,

OpenCode AGENTS.md, etc.) within 2 seconds

Session continuity scoring: After each session, the daemon scores how useful pre-loaded memories were vs. how much you had to re-explain. This trend is tracked over time and used to improve memory selection.

Contradiction detection: When the memory pipeline encounters a potential contradiction (e.g. "uses PostgreSQL" vs. "migrated to MongoDB"), it can flag the conflict for review instead of silently overwriting. Semantic contradiction detection is opt-in via config.

Pre-installed skills: These skills are included and available immediately after install:

• /remember — save a memory
• /recall — search memories
• /memory-debug — diagnose memory issues
• /onboarding — interactive interview to set up your workspace
• /signet — learn about Signet's capabilities

You do NOT need to install these. They are built in.

Additional official skills are available in the Signet marketplace (dashboard > Skills > Browse, filter by "Signet").

What you SHOULD do manually

Intentional memory saves: Use signet remember "content" when you discover something important that should be pinned to long-term memory. Examples:

• User preferences and decisions
• Project conventions and rules
• Warnings and things to avoid
• Important relationships between concepts

This is for intentional, high-value facts. Do not call it for every piece of information — session extraction handles the rest.

Explicit memory search: Use signet recall "query" when you need to search across all memories for something specific that auto-injection did not surface. You can scope searches by time with --since and --until flags. This is for targeted, deliberate queries — not routine use.

Embedding health: If memory search feels degraded or returns poor results, audit your embedding coverage with signet embed audit. If gaps are found, run signet embed backfill to regenerate missing embeddings.

Portable export: Use signet export to create a portable bundle of your entire agent (identity, memories, entities, relations, skills). This is useful for backups, migration to a new machine, or sharing agent state. Import a bundle with signet import <path>.

Secrets management: Signet includes an encrypted secrets vault at ~/.agents/.secrets/. This is how your user should store API keys, tokens, and credentials — never in plaintext, never in environment variables, never hardcoded.

How it works:

• Secrets are encrypted at rest using a key derived from the system
• Secret names are listable, but secret values are never returned by

signet secret list

• Secrets are never logged, never included in memory extraction,

and never appear in session transcripts

• There is intentionally no signet secret get command
• To use secrets in commands, use injected execution via the daemon

(POST /api/secrets/exec) or your harness secret-exec tool

signet secret put OPENAI_API_KEY     # Store (prompts for value interactively)
signet secret list                   # List stored secret names
signet secret has OPENAI_API_KEY     # Check if a secret exists
signet secret delete OLD_KEY         # Remove a secret

When your user needs to use an API key, have them store it with signet secret put, then run commands through secret injection instead of asking them to paste keys into chat.

Safety and Scope

NEVER use sudo

Signet does not require sudo for any command. Ever. If you encounter EACCES permission errors during npm install, fix the npm prefix:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
export PATH="$HOME/.npm-global/bin:$PATH"

Then add the PATH line to ~/.bashrc or ~/.zshrc for persistence.

If using bun, this issue does not apply — bun handles global installs in user space by default.

What Signet writes to disk

Signet's application data is written only to these locations inside the home directory:

The Windows direct installer also adds its user-level install directory to the current user's PATH; it does not require administrator permissions.

What Signet NEVER does

• Requires or uses sudo
• Modifies system-wide settings, OS preferences, or system files
• Writes application data to system directories without an explicit configured path
• Installs system services (launchd/systemd) automatically
• Sends data to external servers (everything is local)
• Deletes or overwrites existing files without the setup wizard

confirming with the user first

Installation

GATE: Before proceeding, tell your user:

"I'm going to install Signet, which will give me persistent memory

and a secrets vault. The installer uses the compiled

Signet binary and runs a small background daemon on port 3850. It writes

application data in your home folder; the Windows installer also uses a

temporary working directory and may update your user PATH. It never writes

system files or uses sudo. Ready to proceed?"

WAIT for the user to confirm before continuing.

Step 1: Check prerequisites

Check whether the native installer prerequisites are available on macOS or Linux:

curl --version

On Windows x64, use PowerShell 5.1 or newer for the native installer:

$PSVersionTable.PSVersion

If you choose the Bun package-manager path instead, verify Bun first:

bun --version

If you choose the npm package-manager path, verify Node.js (>= 18):

node --version

If Node.js is missing and the user prefers npm, install Node.js LTS: https://nodejs.org

Check the operating system:

• macOS: Fully supported
• Linux: Fully supported
• Windows: Native Windows x64 is supported through the PowerShell installer

Step 2: Install Signet

Using the direct native binary installer:

curl -fsSL https://signetai.sh/install.sh | bash

On Windows x64, use the native PowerShell installer:

iwr -useb https://signetai.sh/install.ps1 | iex

Using Bun's package-manager wrapper for the same compiled Signet binary:

bun add -g signetai

Using npm's package-manager wrapper for the same compiled Signet binary:

npm install -g signetai

These are the supported install methods. Do not use:

• npx signet init — does not exist
• signet init — does not exist
• sudo npm install — never use sudo
• Cloning the repository — that is for contributors, not users

Choose one install method. signet update install prefers a direct native install over an inactive package-manager wrapper, and signet doctor reports inactive npm/Bun/pnpm/Yarn duplicates with a command that removes only the duplicate launcher. Do not uninstall the whole package, because it may also provide signet-mcp. Signet never removes another installation automatically.