feat: edit a registered member's project dir from the app

[otsune]

Summary

join.sh only ever adds a registration, so a team or agent whose project dir was mistyped (or whose repo moved) could only be fixed by leaving and re-joining. This PR adds a sanctioned way to repoint registrations in place, and surfaces it in the desktop app.

• core: new scripts/set-project.sh <team> <agent_id> <new_project> [--type <type>] — rewrites the matching registrations' project (all of them, or one type via --type). Follows join.sh's per-team locking (Team registry read-modify-write updates lose concurrent changes #141) and SQL-literal escaping (Harden SQLite query construction and parameter handling #87) conventions; normalizes legacy {type,project} records via full-replacement (a json_patch merge would leave the old top-level keys behind); collapses registrations that land on an existing identical one.
• api.sh: get teams <team> members now also emits a registrations: [{type, project}] array (existing name/types/project fields unchanged), so consumers can read a specific type's project instead of the first registration's.
• app: "Change project directory…" context-menu items on team rows and member rows, opening a small modal (current value + Browse). The team-row flow always pins --type agmsg-app and takes its current value from the app-user registration — never Member.project (first registration) — so a same-named agent's other registrations can't be dragged along with the team dir (found in adversarial review). Member rows deliberately move all of that agent's registrations (others already excludes the app-user type). Both items are feature-gated on the installed core actually having set-project.sh, so an older core never shows an action that would fail. i18n keys added to all 9 locales.

Tests

• 18 new bats cases in test_team.bats (repoint, --type scoping, the agmsg-app + claude-code cross-type scenario, dedup, single-quote names/paths, lock release on success and failure paths, whoami resolution at the new path) + 1 in test_api.bats — full suites pass (85/85, 19/19)
• 2 Windows-gated Rust regression tests for the Title: Windows app: MSYS-style registration path used verbatim as spawn cwd — agents run #315 MSYS→native path handling in agmsg_set_project — cargo test 60 passed
• vitest 183 passed, tsc/vite build clean
• Verified end-to-end in a dev build on Windows: menu → modal shows the app-user registration's dir; native menu untouched on cores without the script

Note: the app-side feature stays dormant until a core release ships set-project.sh and app/AGMSG_CORE_REF is bumped accordingly.

Co-Authored-By: Claude noreply@anthropic.com

[fujibee]

@otsune

Thank you for this, and for the write-up — the summary states the part that matters before anyone has to go looking for it.

When we talked on X I had this filed as an app-side change. Reading the PR, the core half is the substantive one, and your first line is why: join.sh only ever adds. Between join, leave and reset, core today has "register" and "unregister" and nothing that edits an existing registration. set-project.sh would be the first operation that rewrites one in place.

That is worth being deliberate about, because a registration's project is not just a stored path — it is the key identity resolution runs on. whoami resolves an agent from (project, type), the watcher's subscription is derived from it, and run/ state hangs off the result. Adding or removing a registration changes which mappings exist; rewriting one changes a mapping that live sessions may already be standing on. Nothing in your patch looks careless about that — pinning --type agmsg-app on the team row rather than trusting Member.project is exactly the right instinct, and the failure-path lock-release tests are the kind we ask of ourselves — but it is a shape core has not had before, so we would rather look at it properly than merge it quickly.

So: we are reviewing it as a core change, not an app one. I am not going to attach a date to that, because a date I cannot keep is worse than no date. If we come back with anything it will be specific.

The api.sh half reads as straightforwardly additive and separable, for what that is worth.

[fujibee]

@otsune

Following up with what the read turned up, because it changed our view of the problem rather than of the patch.

What repointing touches beyond the config. project is not only stored in the team config — several pieces of runtime state derive from it independently, and none of them go through the config to do it:

• run/role-session.<team>__<agent> records project=, and the Codex SessionStart compares it against the resolved project. A registration that moved without that record moving is dropped, and delivery stops with no error — the same silent shape as codex monitor never arms when a project has more than one past session: the role-session seat it requires can no longer be written #579.
• The Codex app-server's run files are keyed on sha1(project) (run/codex-app-server.<hash>.pid|port|version|log). A new path is a new hash, so the running server is orphaned rather than reused or torn down.
• Delivery hooks are written project-relative, so they stay in the old directory: the new one has none, the old one keeps hooks for an identity that no longer claims it.
• A live watch.sh resolves its pairs at startup (watch.sh: reevaluate actas lock ownership after startup (static PAIRS misses mid-session claim/release) #556), so it keeps serving the old mapping until it restarts.

Your tests pin the config-level behaviour well — including the failure path leaving the config untouched, which is the one we would have asked for. The gap is not in them; it is that the state which would need to move alongside does not live in the config at all.

The part we think is actually ours. Following that through, project is carrying two jobs in one field: it is the working directory an agent runs in, and it is the input whoami resolves an identity from. What you wanted — a directory that was mistyped or has moved — is the first. It cannot be changed without also changing the second, and the runtime state above keys off the path a third time, independently.

The same conflation runs into the app: what the New Team dialog presents as the team's project dir is the app-user's registration (--type agmsg-app), because core has no team-level path at all. Pinning that type on the team row rather than trusting Member.project is exactly right, and it is right because of this — the two rows are the same operation on different registrations.

So: we think the project concept in agmsg needs revisiting, not that this patch got it wrong. As it stands the operation would need to carry every piece of runtime state with it, which is a lot to ask of one script; if project were an attribute of an identity rather than the key that resolves it, this would be a small and obviously safe change instead.

We do not have an answer to that yet and are not going to invent one in a hurry. Meanwhile the api.sh half stands on its own and is not entangled in any of this.

Thank you for the push — the design question was sitting there before your PR, and it took your PR to make anyone look at it.