docs: design — me claude install (global) vs init (project + capture activation) by cevian · Pull Request #130 · timescale/memory-engine

cevian · 2026-07-02T11:41:12Z

No description provided.

Copilot

Pull request overview

Adds a new usage-focused design document proposing a clearer Claude Code integration split between a global me claude install (tools everywhere, capture inert) and a project-scoped me claude init (committed setup + .me/config.yaml that activates capture via a “project tree root” pin).

Changes:

Introduces CLAUDE_INTEGRATION_DESIGN.md describing the proposed install vs init responsibilities and user journeys.
Documents a capture-activation rule: live capture only runs when a project tree root is resolvable (via .me/config.yaml tree or pinned tree_root).
Calls out implementation blockers/open questions (notably scope-blind plugin install detection via claude plugin list --json).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

+Analogy people already hold: `install` = "add the tool for me" (like `npm i
+-g`); `init` = "initialize *this* project" (like `git init`) — and initializing
+a project is what *activates* capture.


+   be skipped.
+```


Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

+- **Claude Code sessions** — backfill this repo's past sessions; install the
+  plugin so future sessions are captured (installed **globally, user scope**).
+- **Git history** — backfill the repo's commit history; install a post-commit


+Project config
+  ◉ Add a memory pointer to CLAUDE.md


+- Backfills this repo's past Claude sessions + git history, installs the plugin
+  (user scope) and the git post-commit hook, and adds the CLAUDE.md pointer.


+- The hook has no "should I capture here?" gate: `resolveHookConfigFromEnv`
+  defaults `treeRoot` to `share.projects` and captures **any** session into
+  `<share.projects>.<slug>.agent_sessions`. So a single global install quietly
+  captures every project you ever open.


+- `me claude init` — hardcodes **user** scope (`claude.ts:615`), even though
+  every other init step (session backfill, git hook, CLAUDE.md pointer) is
+  scoped to *this* repo.


jgpruitt · 2026-07-02T13:39:37Z

+```
+Name for the new agent:
+> claude-code-agent-my-project
+```
+
+- Pre-filled with `claude-code-agent-<project-slug>` (`<project-slug>` is the same


I don't think we want a prefix to the agent name. There's one .me/ per project, and I might use multiple kinds of harnesses within that project.

jgpruitt · 2026-07-02T13:41:08Z

+- `my-project` is a **slug derived from the current directory**.
+- The prefix follows step 1 (`/share/projects/…` for public, `~/projects/…` for


I was going to ask if we could derive the name from the git repo if there's a .git, but it's easy enough to type it in. e.g. I have the memory engine repo checked out to me0, me1, me2, me3 directories.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 9 comments.

+### Commands
+
+- me claude install - installs the plugin
+- me project init - initializes the project config


+enabled:
+
+- `me claude install` — `--scope` flag, defaults to **user** (global).
+- `me claude init` — hardcodes **user** scope (`claude.ts:615`), even though


+- **project tree root** — the ltree path this project's memories nest
+  under. This is the existing `.me/config.yaml` **`tree`** field
+  (`project-config.ts:67`) and the capture hook's `projectTree`
+  (`capture.ts:58`). Memories land at `<tree>/agent_sessions` (no slug appended).


+  one — with **no per-scope `--as-agent` baking** and no `.me` sentinel plumbing.
+- So "do we use an agent?" is an **independent overlay** that bolts onto *either*
+  design identically (add `agent` to the `.me` resolution layer; the field
+  already exists in the schema, parsed but unwired — `project-config.ts:72`).


+
+Claude Code sessions
+  ◉ Import this project's existing Claude Code sessions (one-time backfill)
+  ◉ Install the Claude Code plugin — captures new sessions going forward (+ slash commands, MCP)


+
+4. Setup steps to run:
+   ◉ Import this project's existing Claude Code sessions (one-time backfill)
+   ◉ Install the Claude Code plugin — captures new sessions going forward (+ slash commands, MCP)


+- **Claude Code sessions** — backfill this repo's past sessions; install the
+  plugin so future sessions are captured (installed **globally, user scope**).


+- Backfills this repo's past Claude sessions + git history, installs the plugin
+  (user scope) and the git post-commit hook, and adds the CLAUDE.md pointer.


+Project config
+  ◉ Add a memory pointer to CLAUDE.md
+```


Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

+# Claude Code integration — `me claude install` + `me project init`
+
+Status: **proposal / design** (not implemented). Reconciled with the meeting
+notes below: **one** user-scoped plugin (`me claude install`) that reads a
+project's `.me/config.yaml` with global fallback, plus a harness-agnostic
+`me project init` that writes that config. Capture works out of the box,


+enabled — always into the *shared* `share.projects.<slug>`:
+
+- `me claude install` — `--scope` flag, defaults to **user** (global).
+- `me claude init` — hardcodes **user** scope (`claude.ts:615`), even though


+- **project tree root** — the ltree path memories nest under: the
+  `.me/config.yaml` **`tree`** field (`project-config.ts:67`) / the hook's
+  `projectTree` (`capture.ts:58`). Memories land at `<tree>/agent_sessions` (no
+  slug appended when set explicitly).


+> strict* partly for the `PROJECT_CONFIG_DESIGN.md` cooperative-scoping threat
+> model. Making agent resolution *automatic* from a committed `.me/config` means
+> a repo's `.me` names the agent you act as. This is almost certainly safe — the
+> server validates `X-Me-As-Agent` against your PAT and `agent_tree_access`
+> clamps to `least(agent, owner)`, so a hostile `.me` either names an agent you
+> control or fails auth — but it trades away an opt-in John chose on purpose.


+Next, the wizard shows a grouped, pre-checked multiselect —
+**everything is selected by default**; the user toggles off what they don't want:
+


+# `me claude init` — interactive wizard flow
+
+Status: **target interactive flow** (design; companion to
+`CLAUDE_INTEGRATION_DESIGN.md`).


Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

+`me project init` that writes that config. Capture works out of the box,
+**private by default**, and is shared only when a project opts in.
+
+## Meeting notes (jul 2)


+### Principles
+
+- make install simple
+- push down as much logic as possible to the config - so can share across harness


+enabled — always into the *shared* `share.projects.<slug>`:
+
+- `me claude install` — `--scope` flag, defaults to **user** (global).
+- `me claude init` — hardcodes **user** scope (`claude.ts:615`), even though


+- **project tree root** — the ltree path memories nest under: the
+  `.me/config.yaml` **`tree`** field (`project-config.ts:67`) / the hook's
+  `projectTree` (`capture.ts:58`). Memories land at `<tree>/agent_sessions` (no
+  slug appended when set explicitly).


+  one — with **no per-scope `--as-agent` baking** and no `.me` sentinel plumbing.
+- So "do we use an agent?" is an **independent overlay** that bolts onto *either*
+  design identically (add `agent` to the `.me` resolution layer; the field
+  already exists in the schema, parsed but unwired — `project-config.ts:72`).


…ent name Address PR #130 review comments: - cevian: add "step 0. Space" — pick which space the project lives in (defaults to active space, written as required `space:`; server pinned alongside). Update flow overview (five steps 0-4), example flow, and enter-count. - jgpruitt: default new agent name is now `<slug>-agent` (no `claude-code-` harness prefix) — one `.me/` can serve multiple harnesses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

+enabled — always into the *shared* `share.projects.<slug>`:
+
+- `me claude install` — `--scope` flag, defaults to **user** (global).
+- `me claude init` — hardcodes **user** scope (`claude.ts:615`), even though


+- **project tree root** — the ltree path memories nest under: the
+  `.me/config.yaml` **`tree`** field (`project-config.ts:67`) / the hook's
+  `projectTree` (`capture.ts:58`). Memories land at `<tree>/agent_sessions` (no


+# .me/config.yaml  (committed)
+server: https://api.memory.build   # where memories go
+space: acme-eng                    # the X-Me-Space
+tree: /share/projects/my-repo      # public → shared; default is private ~/projects/<slug>
+capture: true                      # collect this project's agent sessions (default on)
+```


+- **Session capture** — a toggle (default on) writes a **`capture`** flag; the
+  already-installed plugin's hooks honor it, so a project can **opt out** of
+  collecting its agent sessions (e.g. a sensitive repo) while still getting the
+  tools + backfill. Absent = on, matching the global default.


+  there). For Claude, it's *also* written to the project **`.claude/settings.json`**
+  `"env": { "ME_AS_AGENT": … }` (committed) so *ad-hoc* `me` calls in Claude's
+  Bash tool act as the agent too. (This second write is Claude-specific — the
+  harness-agnostic `.me/config.yaml` covers the plugin's own paths.)


+So live capture is **on by default** (unless a project sets `capture: false`),
+but **private by default** and **shared only when a project opts in** — a change
+from today's default of the shared `share.projects.<slug>` (see *What changes*).


+- **Claude Code sessions** — backfill this repo's past sessions, and **enable
+  ongoing capture** of new ones for this project. The capturing is done by the
+  already-installed plugin (`me claude install`); this row just turns it on for
+  this project (a flag in `.me/config.yaml`), so a project can opt out.


jgpruitt · 2026-07-02T18:11:16Z

+Which space should this project use?
+  ● acme-eng (active)   — your current active space
+  ○ personal
+  ○ acme-research


I could see "create a new space" being a helpful option too.

jgpruitt · 2026-07-02T18:23:46Z

+## 3. Memory access (all vs a subset)
+
+Asks how much of *your* memory Claude in this project should be able to see:
+
+```
+Should Claude see all your memories, or only a subset?
+  ● All (default) — Claude runs as you and can see everything you can
+  ○ A subset — Claude runs as a dedicated agent limited to the memories you choose
+```
+
+- **All** → we **don't** run as an agent; the integration runs as **you** (your
+  login session), so Claude sees every memory you can. No `agent:` is written to
+  `.me/config.yaml`.
+- **A subset** → we run as a **dedicated agent** scoped to the memories you pick,
+  written as `agent:` in `.me/config.yaml`. This opens a follow-up (step 3a) to
+  choose the agent.
+


I don't agree with this framing.
I want an agent so I have the ability to constrain its access.
I would want an agent created and given write@/. By default, it can read/write whatever I can, but I can then customize its access however I wish.

The choice should be more like:

run with my user credentials

use one of my existing agents

create a new agent with full access

create a new agent with scoped access

I agree, but I'd eliminate the "run with my user credentials" and simplify this step to:

* use an existing agent * create a new agent

If new, prompt for a name. Either way, then display the current access, and ask how to modify (easy options to toggle read/write for the project root, plus a way to modify other rules).

The default should be "use one of my existing agents" unless the user has no agents. In which case, the default should be "create a new agent with full access"

I'd be fine with eliminating "run with my user credentials"

jgpruitt · 2026-07-02T18:31:52Z

+  ◉ Import existing git commit history (one-time backfill)
+  ◉ Install a git post-commit hook — captures new commits going forward
+Project config
+  ◉ Add a memory pointer to CLAUDE.md


Suggested change

◉ Add a memory pointer to CLAUDE.md

◉ Add a memory pointer to CLAUDE.md / AGENTS.md

Ideally, we'd do both in an intelligent way. One might be symlinked to the other. If not, write to both.

jgpruitt · 2026-07-02T18:42:49Z

+3. Should Claude see all your memories, or only a subset?
+   > ● All                                      ⏎
+     └─ "All" → no agent, so steps 3a/3ab/3ac are skipped.


I don't agree that this should be the default. If I realize later "oh yeah, it would be nice if my harness couldn't see/edit /x/y/z" it's more difficult to fix if this is the default. I have to now provision an agent, set up its access, and reconfigure the plugin. Not terribly hard, but more steps than it has to be.

If creating an agent with write@/ is the default, then constraining the harness later is just a matter of adjusting the agent's access.

If the default is "use my credentials," then we should not have wasted our time creating a special kind of principal for agents that an owner can self-administer that has access capped by the owner. THIS IS THE USE CASE RIGHT HERE.

jgpruitt · 2026-07-02T19:10:43Z

+## 3. Memory access (all vs a subset)
+
+Asks how much of *your* memory Claude in this project should be able to see:
+
+```
+Should Claude see all your memories, or only a subset?
+  ● All (default) — Claude runs as you and can see everything you can
+  ○ A subset — Claude runs as a dedicated agent limited to the memories you choose
+```
+
+- **All** → we **don't** run as an agent; the integration runs as **you** (your
+  login session), so Claude sees every memory you can. No `agent:` is written to
+  `.me/config.yaml`.
+- **A subset** → we run as a **dedicated agent** scoped to the memories you pick,
+  written as `agent:` in `.me/config.yaml`. This opens a follow-up (step 3a) to
+  choose the agent.
+


The default should be "use one of my existing agents" unless the user has no agents. In which case, the default should be "create a new agent with full access"

jgpruitt · 2026-07-02T19:39:05Z

+- **Useful with no project config** (principle: *don't require project config to
+  do useful stuff*). On the global config alone the plugin uses your active
+  space/server, runs as **you** (no agent), and captures into your **private**
+  home at **`~/projects/<slug>`** (`<slug>` from the repo). Capture works out of
+  the box — and non-project captures land in your **private** dir, not a shared
+  space.


We've heard multiple people including members of the team say that they DO NOT want ALL their session transcripts streamed into memory engine. I think most people will want certain sessions in certain directories to go into memory engine. I don't understand why we're pushing this. If we make it such that all sessions globally are ingested, I expect:

most users to find that both surprising and alarming

many users hesitate to use memory engine, defaulting to not installing it

I won't install it if I can't turn this off. And if it's the default, the first thing I'll do is turn it off.

fixed to default off

murrayju · 2026-07-02T18:38:55Z

+
+```
+Which space should this project use?
+  ● acme-eng (active)   — your current active space


I don't know if this is meant to be literally what is on the screen, but I wouldn't double-emphasize that it is active.

murrayju · 2026-07-02T18:43:43Z

+## 1. Memory visibility (public vs private)
+
+The wizard's first question decides **where this project's memories live**:
+
+```
+Do you want memories for this project to be public or private?
+  ● Public (recommended) — shared with your whole team; everyone on the space
+    works off the same common memories
+  ○ Private — only you can see this project's memories
+```
+
+- **Default: Public**, and it's the **recommended** choice — the value of project
+  memory is a shared pool the whole team builds on and benefits from (decisions,
+  conventions, history), rather than each person keeping their own silo.
+- **Private** keeps this project's memories in your personal home, visible only to
+  you.
+
+This choice sets the **default** for the next question: **Public** pre-fills a
+path under the space's shared root (`share`); **Private** pre-fills one under your
+personal home (`~`).
+
+## 2. Tree root


These two questions are really the same thing. Can we collapse it into one?

Where should this project's memories live? * /share/projects/my-project ← Public (default) * ~/projects/my-project ← Private * (custom)

These public/private conventions are only true if the space is configured with the default conventions.

@murrayju good idea, changing
@john the wizard has to make some assumptions, but you can always do things manually

murrayju · 2026-07-02T18:46:45Z

+
+## 3. Memory access (all vs a subset)
+
+Asks how much of *your* memory Claude in this project should be able to see:


I don't grok this sentence

Suggested change

Asks how much of *your* memory Claude in this project should be able to see:

Asks how much of *your* space Claude should be able to see when working in this project:

murrayju · 2026-07-02T18:53:56Z

+## 3. Memory access (all vs a subset)
+
+Asks how much of *your* memory Claude in this project should be able to see:
+
+```
+Should Claude see all your memories, or only a subset?
+  ● All (default) — Claude runs as you and can see everything you can
+  ○ A subset — Claude runs as a dedicated agent limited to the memories you choose
+```
+
+- **All** → we **don't** run as an agent; the integration runs as **you** (your
+  login session), so Claude sees every memory you can. No `agent:` is written to
+  `.me/config.yaml`.
+- **A subset** → we run as a **dedicated agent** scoped to the memories you pick,
+  written as `agent:` in `.me/config.yaml`. This opens a follow-up (step 3a) to
+  choose the agent.
+


I agree, but I'd eliminate the "run with my user credentials" and simplify this step to:

* use an existing agent * create a new agent

If new, prompt for a name. Either way, then display the current access, and ask how to modify (easy options to toggle read/write for the project root, plus a way to modify other rules).

murrayju · 2026-07-02T18:56:13Z

+How should the agent for this project be set up?
+  ● This project only — create an agent that can see just this project (default)
+  ○ Reuse an existing agent — pick one of your agents; its existing grants apply
+  ○ Empty agent — create one with no grants; I'll set up its access myself


This is moot given the comments above, but just want to say I think this "empty agent" option is pretty useless. There's no reason to set up a project with an agent that can't access it (or anything).

Records how this design relates to John's clean-slate proposal, for Claude: - Agent identity is orthogonal to the install/init split — it's just an `agent:` field in `.me/config.yaml`, honored by both user- and project-scoped integrations via the existing `.me` resolution layer (which `me mcp` + the hook already inherit). No per-scope `--as-agent` baking needed; the overlay bolts onto either design identically. Notes the automatic-vs-explicit resolution threat-model caveat. - Once identity is factored out, the real forks are just: delivery (marketplace plugin vs direct file writes) and capture default (inert-until-project-tree-root vs always-on + --scope dedup) — and those two are separable/best-of-both. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds CLAUDE_INIT_WIZARD.md — the target interactive flow for `me claude init`: 1. Memory visibility — public (default, recommended) vs private 2. Tree root — freeform, pre-filled from step 1 (/share/projects/<slug> or ~/projects/<slug>), written to .me/config.yaml 3. Memory access — all (default, runs as you, no agent) vs a subset (runs as an agent), with branches: - 3a: this-project-only / reuse-existing / empty-agent - 3ab: pick an existing agent (if reuse) - 3ac: name the new agent, pre-filled claude-code-agent-<slug> (if create) 4. Setup checklist — the existing multiselect (backfills, plugin, git hook, CLAUDE.md pointer) Ends with an example default flow (four enters, no agent branching). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Principles + a "how Claude would work" sketch (one user-scoped plugin that listens to .me/config with global fallback; agent pinned via settings.json env; one-plugin-many-secondary-mcp for power users) and a revised command split (me claude install / me project init), captured from a meeting for follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Normalize whitespace in the meeting-notes block (trailing spaces, 5→4-space nested indent, doubled blank lines, blank-after-heading, drop trailing colons) and fix "intializes" → "initializes". Content/wording unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Align the doc body with the meeting-notes direction: - One user-scoped plugin (me claude install) that reads .me/config with global fallback — drop the user-vs-project plugin-scope split. - me claude init → me project init (harness-agnostic): writes .me/config only, installs no plugin. - Capture default flips from inert-until-opt-in to on-by-default but PRIVATE (~/projects/<slug>); shared only when a project opts in via a public tree. Replaces the "capture-activation rule" with a tree-root resolution order. - Agent conveyed via .me/config + settings.json env var. - Parallel access to other spaces = a secondary MCP server (one-plugin, many-secondary-MCP). - Rewrite open questions (scope-blind-probe blocker is gone) and update the John's-design comparison (capture-default axis has largely converged). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- me claude install now pins global defaults (space + server, tree root ~/projects/, no agent), each independently changeable; add to "what changes". - A project config must pin space + server (self-contained for the team; today all .me/config fields are optional) — reflected in the model, the project-init section, and "what changes". - Clarify the agent is written to .me/config.yaml (harness-agnostic) AND, for Claude, the project .claude/settings.json "env" (Claude-specific Tier-2). - Expand the power-user journey: one plugin + multiple tools-only secondary MCPs, each pinned to a space via a --name flag (distinct tool namespace); update OQ3. - Cut the headless/CI journey (only consumer of api-key pinning + the plugin tree_root resolution rule); drop that rule from the tree-root resolution order. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- me claude init → me project init (title + example), matching the reconciled design. - Remove the "Install the Claude Code plugin" checklist row + its adapt/example references — the single plugin is installed by me claude install, not init. - Checklist is now four rows; flag the remaining Claude/repo-specific steps as a harness-agnostic TODO for a follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- Wizard: add an "Enable ongoing capture of new Claude Code sessions for this project" row (default on) to the setup checklist — the already-installed plugin does the capturing; the row toggles it per-project. - Design: document the backing `.me/config.yaml` `capture` flag (default on; a project can opt out) in the me-project-init section, the example config, and the tree-root resolution note. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ent name Address PR #130 review comments: - cevian: add "step 0. Space" — pick which space the project lives in (defaults to active space, written as required `space:`; server pinned alongside). Update flow overview (five steps 0-4), example flow, and enter-count. - jgpruitt: default new agent name is now `<slug>-agent` (no `claude-code-` harness prefix) — one `.me/` can serve multiple harnesses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Refine the capture model in both docs: - The capture hook ships INERT; capture is off by default. - me claude install ASKS whether to enable capture. On yes it runs `me import claude` once (backfill) and turns the hook on via the global config; on no you get the tools only. - Capture resolution now checks "is capture on?" (project .me/config `capture`, else the global setting) before resolving the tree root. - Team repo: the committed .me/config enables capture even if a teammate never opted into global capture (project setting wins). - Update journeys, what-changes, John's-comparison axis 2, and the wizard's capture-row wording to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The space picker now includes "+ Create a new space…", which prompts for a new space name, provisions it (you become admin/owner), and uses it for the project. Update the flow-overview line to "(or create one)". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…tion Merge steps 1 (public/private) and 2 (tree root) into a single "Where should this project's memories live?" pick: Public (default) / Private / (custom). Renumber the flow to four steps (0-3): memory access → 2 (branches 2a/2ab/2ac), setup checklist → 3. Update all cross-references, the example flow, and the happy-path enter count (now four). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Wizard step 2 becomes "How should an agent for this project be set up?" with three options — new agent (whole space, default) / new agent (this project only) / use an existing agent. The "all / run as your own user (no agent)" option is gone; follow-ups renumber to 2a (name new agent) and 2b (pick existing). Reconcile the design doc: a project's agent is set up by the wizard by default, but the `agent` field stays OPTIONAL in the config (not a hard schema requirement), and the global no-project case still runs as you. Update the model bullet, the .me/config example, and the Agent bullet accordingly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- Rewrite the "What changes vs today" agent bullet: today the .me/config `agent` field is parsed but unwired — the work is to wire it up (me project init configures a whole-space/this-project/existing agent; plugin acts as it). - Add a "Proposed PRs" section (after what-changes) breaking the implementation into 7 PRs with dependencies + a suggested order. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- Fold the Claude Tier-2 env write into PR 2 (me project init is the writer); drop the standalone Tier-2 PR; renumber secondary MCPs. PR 1's commit 2 is the agent read/resolution side (writer is PR 2). Docs ship with each PR. - PR 2 leads with the me claude init → me project init rename. - Add a wizard preflight (before step 0): offer to run me login if not logged in (declining stops) and me claude install if the plugin isn't installed (declining warns), each with a confirmation. Reflect it in PR 2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- PR 2 now references CLAUDE_INIT_WIZARD.md for the full wizard flow. - PR 1 commit 1 specifies adding the `capture` key to both .me/config and the global ~/.config/me config. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Act-as-agent (X-Me-As-Agent + the .me sentinel) already landed on main, so PR 1's original "wire up the agent field" commit is done. Re-plan the remaining work as three commits: capture gating (capture key + inert, private hook), me import claude reading its tree from config, then the me claude install rework. Reconcile the stale design-body claims (agent field now wired via the explicit sentinel, not automatic resolution) and resolve the open questions accordingly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

+- **Pins the global defaults** into your `~/.config/me` config: your **space** +
+  **server** (the currently resolved/active ones), a global **tree root of
+  `~/projects/`** (so captures, once on, land in `~/projects/<slug>`), and **no
+  agent** (runs as you). **Each is independently changeable** — edit the global
+  config (or the `me` commands that manage it), or override per-project via
+  `.me/config.yaml`.


+- **Session capture** — a toggle (default on) writes a **`capture`** flag; the
+  already-installed plugin's hooks honor it, so a project can **opt out** of
+  collecting its agent sessions (e.g. a sensitive repo) while still getting the
+  tools + backfill. Absent = on, matching the global default.


+- **Visibility** — *public* nests the project tree root under the shared `share`
+  (team-wide); *private* under your home `~` (the default).


PR 1 commit 2 resolves the .me tree once from the process CWD, which only fits a single-project (--project-scoped) run. Move the per-session .me resolution for bare multi-project sweeps out of the commit-2 caveat into its own follow-up PR 4 (deps: PR 1's commit 2), and repoint the ordering + open-question references. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Expand the PR 2 entry into a code-grounded plan: (1) config + settings writers (a general .me/config.yaml writer, a .claude/settings.json env merge, and a fix so the CLAUDE.md pointer honors a custom tree), (2) the wizard's preflight + prompts + agent provisioning, (3) the setup checklist + retiring me claude init. settings.json ME_AS_AGENT is the literal agent name, not the .me sentinel: Claude's Bash tool runs from an arbitrary cwd where a .me walk-up wouldn't resolve. Add open q5 for the agent grant level + me claude init disposition. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…t privacy - PR 1 install backfill is a machine-wide me import claude sweep (install is global, not repo-scoped) → private ~/projects/<slug>. - PR 2 agent grant is write (access 2), not owner — clamp is inherited per-path, so a root grant = exactly what the caller can reach. - Reconcile the me claude install body with commit 3: only server + space (+ capture) persist to ~/.config/me; ~/projects tree root and "no agent" are code defaults, not persisted keys. - me import git also defaults to private ~/projects (unify privacy defaults); DEFAULT_TREE_ROOT = share.projects kept only for explicit opt-ins/headless pins. - Add follow-ups (not scheduled): de-dup/move across trees; make me project init truly harness-agnostic (Claude-first for now). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

+- **Session capture** — a toggle (default on) writes a **`capture`** flag; the
+  already-installed plugin's hooks honor it, so a project can **opt out** of
+  collecting its agent sessions (e.g. a sensitive repo) while still getting the
+  tools + backfill. Absent = on, matching the global default.


+  agent. Its name is written to `.me/config.yaml` (harness-agnostic — the plugin's
+  hooks + MCP read it) and, for Claude, *also* to the project
+  **`.claude/settings.json`** `"env": { "ME_AS_AGENT": "<agent name>" }` (committed)
+  so *ad-hoc* `me` calls in Claude's Bash tool act as the agent too. It's the
+  **literal agent name**, not the `.me` sentinel: the Bash tool runs from an
+  arbitrary cwd, where a `.me` walk-up wouldn't find the project config.


Fold the resolved grant-level decision into the open-questions list so it no longer contradicts PR 2 commit 2 (which already specifies access 2). q5(b), the me claude init alias-vs-removal disposition, stays open. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

X-Me-As-Agent resolves only against the caller's own agents, so a single committed agent:/ME_AS_AGENT works only for the creator; teammates 403. Record the options (per-user agent, capture-as-self, or a shared/space-owned agent) and note the Team-repo journey needs fixing to match whatever is chosen. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot AI review requested due to automatic review settings July 2, 2026 11:41

Copilot started reviewing on behalf of cevian July 2, 2026 11:42 View session