refactor: move OAuth storage and drop legacy sessions
This commit is contained in:
Peter Steinberger
@@ -1,12 +1,12 @@
|
||||
---
|
||||
summary: "Agent runtime (embedded Pi), workspace contract, and session bootstrap"
|
||||
summary: "Agent runtime (embedded p-mono), workspace contract, and session bootstrap"
|
||||
read_when:
|
||||
- Changing agent runtime, workspace bootstrap, or session behavior
|
||||
---
|
||||
<!-- {% raw %} -->
|
||||
# Agent Runtime 🤖
|
||||
|
||||
CLAWDIS runs a single agent runtime: **Pi (embedded, in-process)**.
|
||||
CLAWDIS runs a single embedded agent runtime derived from **p-mono** (internal name: **p**).
|
||||
|
||||
## Workspace (required)
|
||||
|
||||
@@ -30,7 +30,7 @@ If a file is missing, CLAWDIS injects a single “missing file” marker line (a
|
||||
|
||||
## Built-in tools (internal)
|
||||
|
||||
Pi’s embedded core tools (read/bash/edit/write and related internals) are defined in code and always available. `TOOLS.md` does **not** control which tools exist; it’s guidance for how *you* want them used.
|
||||
p’s embedded core tools (read/bash/edit/write and related internals) are defined in code and always available. `TOOLS.md` does **not** control which tools exist; it’s guidance for how *you* want them used.
|
||||
|
||||
## Skills
|
||||
|
||||
@@ -41,11 +41,12 @@ Clawdis loads skills from three locations (workspace wins on name conflict):
|
||||
|
||||
Skills can be gated by config/env (see `skills.*` in `docs/configuration.md`).
|
||||
|
||||
## SDK integration
|
||||
## p-mono integration
|
||||
|
||||
The embedded agent uses the `@mariozechner/pi-coding-agent` SDK for sessions and discovery.
|
||||
- Hooks, custom tools, and slash commands are discovered via the SDK (from `~/.pi/agent` and `<workspace>/.pi` settings).
|
||||
- Bootstrap files are injected as SDK project context (see “Project Context” in the system prompt).
|
||||
Clawdis reuses pieces of the p-mono codebase (models/tools), but **session management, discovery, and tool wiring are Clawdis-owned**.
|
||||
|
||||
- No p-coding agent runtime.
|
||||
- No `~/.pi/agent` or `<workspace>/.pi` settings are consulted.
|
||||
|
||||
## Peter @ steipete (only)
|
||||
|
||||
@@ -65,6 +66,7 @@ Session transcripts are stored as JSONL at:
|
||||
- `~/.clawdis/sessions/<SessionId>.jsonl`
|
||||
|
||||
The session ID is stable and chosen by CLAWDIS.
|
||||
Legacy Pi/Tau session folders are **not** read.
|
||||
|
||||
## Steering while streaming
|
||||
|
||||
|
||||
@@ -20,13 +20,13 @@ App bundle layout:
|
||||
- `clawdis …` (CLI)
|
||||
- `clawdis gateway-daemon …` (LaunchAgent daemon)
|
||||
- `Clawdis.app/Contents/Resources/Relay/package.json`
|
||||
- tiny “Pi compatibility” file (see below)
|
||||
- tiny “p runtime compatibility” file (see below)
|
||||
- `Clawdis.app/Contents/Resources/Relay/theme/`
|
||||
- Pi TUI theme payload (optional, but strongly recommended)
|
||||
- p TUI theme payload (optional, but strongly recommended)
|
||||
|
||||
Why the sidecar files matter:
|
||||
- `@mariozechner/pi-coding-agent` detects “bun binary mode” and then looks for `package.json` + `theme/` **next to `process.execPath`** (i.e. next to `clawdis`).
|
||||
- So even if bun can embed assets, Pi currently expects filesystem paths. Keep the sidecar files.
|
||||
- The embedded p runtime detects “bun binary mode” and then looks for `package.json` + `theme/` **next to `process.execPath`** (i.e. next to `clawdis`).
|
||||
- So even if bun can embed assets, the runtime expects filesystem paths. Keep the sidecar files.
|
||||
|
||||
## Build pipeline
|
||||
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
summary: "Planned first-run onboarding flow for Clawdis (local vs remote, Anthropic OAuth, workspace bootstrap ritual)"
|
||||
read_when:
|
||||
- Designing the macOS onboarding assistant
|
||||
- Implementing Pi authentication or identity setup
|
||||
- Implementing Anthropic auth or identity setup
|
||||
---
|
||||
<!-- {% raw %} -->
|
||||
# Onboarding (macOS app)
|
||||
|
||||
This doc describes the intended **first-run onboarding** for Clawdis. The goal is a good “day 0” experience: pick where the Gateway runs, bind Claude (Anthropic) auth for Pi, and then let the **agent bootstrap itself** via a first-run ritual in the workspace.
|
||||
This doc describes the intended **first-run onboarding** for Clawdis. The goal is a good “day 0” experience: pick where the Gateway runs, bind Claude (Anthropic) auth for the embedded agent runtime, and then let the **agent bootstrap itself** via a first-run ritual in the workspace.
|
||||
|
||||
## Page order (high level)
|
||||
|
||||
@@ -19,58 +19,42 @@ This doc describes the intended **first-run onboarding** for Clawdis. The goal i
|
||||
|
||||
First question: where does the **Gateway** run?
|
||||
|
||||
- **Local (this Mac):** onboarding can run the Anthropic OAuth flow and write Pi’s token store locally.
|
||||
- **Local (this Mac):** onboarding can run the Anthropic OAuth flow and write the Clawdis token store locally.
|
||||
- **Remote (over SSH/tailnet):** onboarding must not run OAuth locally, because credentials must exist on the **gateway host**.
|
||||
|
||||
Implementation note (2025-12-19): in local mode, the macOS app bundles the Gateway and enables it via a per-user launchd LaunchAgent (no global npm install/Node requirement for the user).
|
||||
|
||||
## 2) Local-only: Connect Claude (Anthropic OAuth)
|
||||
|
||||
This is the “bind Pi to Clawdis” step. It is explicitly the **Anthropic (Claude Pro/Max) OAuth flow**, not a generic “login”.
|
||||
This is the “bind Clawdis to Anthropic” step. It is explicitly the **Anthropic (Claude Pro/Max) OAuth flow**, not a generic “login”.
|
||||
|
||||
### Recommended: OAuth
|
||||
|
||||
The macOS app should:
|
||||
- Start the Anthropic OAuth (PKCE) flow in the user’s browser.
|
||||
- Ask the user to paste the `code#state` value.
|
||||
- Exchange it for tokens and write Pi-compatible credentials to:
|
||||
- `~/.pi/agent/oauth.json` (file mode `0600`, directory mode `0700`)
|
||||
- Exchange it for tokens and write credentials to:
|
||||
- `~/.clawdis/credentials/oauth.json` (file mode `0600`, directory mode `0700`)
|
||||
|
||||
Why this location matters: it makes Pi work immediately (Clawdis doesn’t need a terminal and doesn’t need to re-implement Pi’s auth plumbing later).
|
||||
Why this location matters: it’s the Clawdis-owned OAuth store.
|
||||
On first run, Clawdis can import existing OAuth tokens from legacy p/Claude locations if present.
|
||||
|
||||
### Alternative: API key (instructions only)
|
||||
|
||||
Offer an “API key” option, but for now it is **instructions only**:
|
||||
- Get an Anthropic API key.
|
||||
- Provide it to Pi (or to Clawdis’s Pi invocation) via your preferred mechanism.
|
||||
- Provide it to Clawdis via your preferred mechanism (env/config).
|
||||
|
||||
Note: environment variables are often confusing when the Gateway is launched by a GUI app (launchd environment != your shell).
|
||||
|
||||
### Provider/model safety rule
|
||||
|
||||
Clawdis should **always pass** `--provider` and `--model` when invoking Pi (don’t rely on Pi defaults).
|
||||
Clawdis should **always pass** `--provider` and `--model` when invoking the embedded agent (don’t rely on defaults).
|
||||
|
||||
Until that is hard-coded, the equivalent configuration is:
|
||||
Example (CLI):
|
||||
|
||||
```json5
|
||||
{
|
||||
inbound: {
|
||||
reply: {
|
||||
mode: "command",
|
||||
command: [
|
||||
"pi",
|
||||
"--mode",
|
||||
"rpc",
|
||||
"--provider",
|
||||
"anthropic",
|
||||
"--model",
|
||||
"claude-opus-4-5",
|
||||
"{{BodyStripped}}"
|
||||
],
|
||||
agent: { kind: "pi", format: "json" }
|
||||
}
|
||||
}
|
||||
}
|
||||
```bash
|
||||
clawdis agent --mode rpc --provider anthropic --model claude-opus-4-5 "<message>"
|
||||
```
|
||||
|
||||
If the user skips auth, onboarding should be clear: the agent likely won’t respond until auth is configured.
|
||||
@@ -136,10 +120,10 @@ Daily memory lives under `memory/` in the workspace:
|
||||
|
||||
## Remote mode note (why OAuth is hidden)
|
||||
|
||||
If the Gateway runs on another machine, the Anthropic OAuth credentials must be created/stored on that host (where Pi runs).
|
||||
If the Gateway runs on another machine, the Anthropic OAuth credentials must be created/stored on that host (where the agent runtime runs).
|
||||
|
||||
For now, remote onboarding should:
|
||||
- explain why OAuth isn’t shown
|
||||
- point the user at the credential location (`~/.pi/agent/oauth.json`) and the workspace location on the gateway host
|
||||
- point the user at the credential location (`~/.clawdis/credentials/oauth.json`) and the workspace location on the gateway host
|
||||
- mention that the **bootstrap ritual happens on the gateway host** (same BOOTSTRAP/IDENTITY/USER files)
|
||||
<!-- {% endraw %} -->
|
||||
|
||||
@@ -18,6 +18,7 @@ All session state is **owned by the gateway** (the “master” Clawdis). UI cli
|
||||
- Store file: `~/.clawdis/sessions/sessions.json` (legacy: `~/.clawdis/sessions.json`).
|
||||
- Transcripts: `~/.clawdis/sessions/<SessionId>.jsonl` (one file per session id).
|
||||
- The store is a map `sessionKey -> { sessionId, updatedAt, ... }`. Deleting entries is safe; they are recreated on demand.
|
||||
- Clawdis does **not** read legacy Pi/Tau session folders.
|
||||
|
||||
## Mapping transports → session keys
|
||||
- Direct chats (WhatsApp, Telegram, desktop Web Chat) all collapse to the **primary key** so they share context.
|
||||
|
||||
Reference in New Issue
Block a user