@vanillagreen/pi-claude-bridge 1.6.2 → 1.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +33 -2
- package/bundle/index.js +25449 -19866
- package/package.json +5 -5
- package/src/agents-md.ts +16 -6
- package/src/auth-presence.ts +158 -0
- package/src/config.ts +75 -3
- package/src/index.ts +443 -62
- package/src/prompt-context.ts +3 -8
package/README.md
CHANGED
|
@@ -94,6 +94,37 @@ Pi 0.80.6 and newer expose native `max` thinking. Fable 5 bridge metadata forwar
|
|
|
94
94
|
|
|
95
95
|
Keys may be bare model IDs (`claude-opus-4-8`), `claude-bridge/<id>`, or `*` for all bridge models. Values are `low`, `medium`, `high`, `xhigh`, or `max`.
|
|
96
96
|
|
|
97
|
+
### Connectors
|
|
98
|
+
|
|
99
|
+
The bridge can expose the authenticated Claude account's claude.ai cloud MCP connectors (Gmail, Google Calendar, Google Drive) to the model. These are low-level `provider` options (set in `settings.json` under the extension-manager config, or via env). Off by default so Pi owns tool execution.
|
|
100
|
+
|
|
101
|
+
| Option (`provider.*`) | Env var | Values | Default | What it does |
|
|
102
|
+
| --- | --- | --- | --- | --- |
|
|
103
|
+
| `enableConnectors` | `CLAUDE_BRIDGE_ENABLE_CONNECTORS` | `true`/`false` | off | Expose the account's Gmail/Calendar/Drive connectors to the model (env OR config enables). |
|
|
104
|
+
| `connectorWriteMode` | `CLAUDE_BRIDGE_CONNECTOR_WRITE` | `deny`/`allow` | `deny` | When connectors are enabled, whether their WRITE tools are exposed. |
|
|
105
|
+
|
|
106
|
+
For both, the env var wins over config. `connectorWriteMode` only matters when connectors are enabled. Any value other than exactly `allow` is treated as `deny` (fail-closed).
|
|
107
|
+
|
|
108
|
+
With `connectorWriteMode: "deny"` (the default), connector sessions are **read-only**: search/read/fetch/list tools stay available, but mutating tools (Gmail `create_draft`/labels, Calendar `create_event`/`update_event`/`delete_event`/`respond_to_event`, Drive `create_file`/`copy_file`) are denied. Enforcement is two-layered:
|
|
109
|
+
|
|
110
|
+
- **Model context:** the known write tools are passed as `disallowedTools` (exact tool ids), so the model does not see them. (Note: the CLI's MCP permission matcher only supports exact tool names or a whole-server `mcp__server__*` glob — partial tool-segment globs are inert — so exact ids are what actually removes today's writes.)
|
|
111
|
+
- **Runtime:** a `PreToolUse` hook blocks any connector tool classified as a write at call time, regardless of permission mode. Classification is **fail-closed** — a tool on a connector namespace is a write unless its verb is a known read prefix (`list_`, `search_`, `get_`, `read_`, `fetch_`, …). This covers not-yet-known write tools (e.g. a future Gmail `send_message` or Drive `delete_file`) that the static id list can't enumerate.
|
|
112
|
+
|
|
113
|
+
Set `allow` only for a one-shot write-executor session that has already obtained explicit user approval — never for an interactive connector chat.
|
|
114
|
+
|
|
115
|
+
> **`allow` is per-process, not global.** Memsira's approved-write executor enables writes by setting `CLAUDE_BRIDGE_CONNECTOR_WRITE=allow` in the **child env of a dedicated one-shot process** that runs the single approved write and exits. Do not set `connectorWriteMode: "allow"` in persistent `settings.json` (or `allow` process-globally) for a shared/long-lived sidecar — that would make every connector session in that process write-capable, defeating the approval gate.
|
|
116
|
+
|
|
117
|
+
### Isolated mode (embedding hosts)
|
|
118
|
+
|
|
119
|
+
Host apps that embed the bridge and own every config dir explicitly can set `CLAUDE_BRIDGE_ISOLATED=1` in the bridge process env. Isolated mode disables every cwd/home discovery fallback so nothing outside the host-owned dirs is read:
|
|
120
|
+
|
|
121
|
+
- no cwd-ancestor `AGENTS.md` walk — instructions come only from `<PI_CODING_AGENT_DIR>/AGENTS.md`;
|
|
122
|
+
- no project `.pi/settings.json` / `.pi/claude-bridge.json` reads (even for trusted projects);
|
|
123
|
+
- no project `.pi/APPEND_SYSTEM.md`;
|
|
124
|
+
- no `$PATH` search for the `claude` executable — the host either pins `pathToClaudeCodeExecutable` or gets the Claude Agent SDK's bundled default.
|
|
125
|
+
|
|
126
|
+
Config, logs, and `AGENTS.md` all resolve under `PI_CODING_AGENT_DIR`. Normal pi CLI usage (flag unset) is unchanged.
|
|
127
|
+
|
|
97
128
|
### Fable 5 caveat
|
|
98
129
|
|
|
99
130
|
The bridge registers `claude-bridge/claude-fable-5`, `claude-bridge/claude-sonnet-5`, and `claude-bridge/claude-opus-4-8` even when Pi's Anthropic model registry has not shipped those entries yet. For Fable 5, the bridge asks Claude Code to use Opus 4.8 as the availability fallback and preserves Claude Code's content-safety fallback events so Pi labels rerouted turns as Opus 4.8. Content-safety fallback still depends on Claude Code's own Fable 5 support; use Claude Code 2.1.170 or newer, and set `ANTHROPIC_DEFAULT_FABLE_MODEL` / `ANTHROPIC_DEFAULT_OPUS_MODEL` yourself when routing provider-specific model IDs through Bedrock, Vertex, or Foundry.
|
|
@@ -110,9 +141,9 @@ If Claude Code accepts a turn but produces no visible output, the bridge returns
|
|
|
110
141
|
|
|
111
142
|
## Debugging
|
|
112
143
|
|
|
113
|
-
Set `CLAUDE_BRIDGE_DEBUG=1` to write bridge logs to
|
|
144
|
+
Set `CLAUDE_BRIDGE_DEBUG=1` to write bridge logs to `<agent dir>/claude-bridge.log` and per-query Claude Code CLI logs under `<agent dir>/cc-cli-logs/`, where `<agent dir>` is `PI_CODING_AGENT_DIR` when set, else `~/.pi/agent`. Override the exact files with `CLAUDE_BRIDGE_DEBUG_PATH` / `CLAUDE_BRIDGE_DIAG_PATH`.
|
|
114
145
|
|
|
115
|
-
Tool-result integrity problems are surfaced even when debug logging is off. Pi shows an error notification and writes a diagnostic file to
|
|
146
|
+
Tool-result integrity problems are surfaced even when debug logging is off. Pi shows an error notification and writes a diagnostic file to `<agent dir>/claude-bridge-diag.log` so lost or mismatched tool output is visible.
|
|
116
147
|
|
|
117
148
|
Startup failures include the resolved Claude executable and working directory, which makes missing binaries and wrong launch directories easier to fix.
|
|
118
149
|
|