NanoClaw
NanoClaw exposes plugin location and host health
NanoClaw proposes honoring each plugin MCP working directory, a lightweight status command that works as an operator probe and a repair for template-stamped agent IDs rejected by OneCLI. The cluster makes execution location, health and identity visible at the host boundary.
nanocoai/nanoclaw PR #3231 is the inspected primary source: “feat(codex,opencode): honor plugin MCP cwd in both provider config writers.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- nanocoai/nanoclaw PR #3231 was created 2026-08-12T06:33:47Z and was open at inspection; its title is “feat(codex,opencode): honor plugin MCP cwd in both provider config writers.” - nanocoai/nanoclaw issue #2504 was created 2026-05-15T21:10:35Z and was open at inspection; its title is “feat: add `ncl status` command for lightweight operational health check.” - nanocoai/nanoclaw issue #3234 was created 2026-08-12T20:41:14Z and was open at inspection; its title is “Template-stamped agent groups get a bare UUID id, missing the `ag-` prefix that keeps OneCLI `ensureAgent` from rejecting it.” - The repository reported 30497 stars, 884 open issues, default branch main, and last push 2026-08-11T16:39:45Z. - The latest tagged-release baseline checked was v2.1.54 published 2026-08-01T20:46:31Z.
What changed
nanocoai/nanoclaw PR #3231 reports: Registry payload half of the plugin MCP working-directory support that lands on trunk with #3220. Codex's stdio MCP transport takes a native cwd (present since before the pinned 0.138.0; launch behavior live-verified on 0.147.0): the TOML writer emits it above the [.env] sub-table header so it stays in the server table, quoted through tomlBasicString like every other value. OpenCode's local entry is a bare argv array with no spawn-directory key, so a declared cwd goes through the shared cd-then-exec wrap (cwd-shim.ts) instead of silently launching in the wrong directory. Twin-patches the engine pieces this payload needs from trunk: the cwd field on McpServerConfig and cwd-shim.ts itself, which trunk's plugin-mcp.ts feeds with plugin cwd declarations resolved to absolute container paths. Relationship to #3220: trunk-side, stamped plugin servers now always carry a cwd (the spec default is the plugin root), so these writers are what makes that take effect on codex and opencode. The add-opencode skill on #3220 fetches cwd-shim.ts from this branch. Merge in the same window as #3220. Verification (registry PRs get no CI): bun
nanocoai/nanoclaw issue #2504 reports: Problem Currently there's no quick way to see the operational health of a running NanoClaw instance. The existing tools are: **ncl sessions list** — shows active sessions but no health signals (container alive? last message? recent errors?) **/add-dashboard skill** — requires an external Pusher account and DASHBOARD_SECRET/DASHBOARD_PORT env vars; high barrier for a personal install **Logs** — logs/nanoclaw.error.log and nanoclaw.log require manual grep The README says "there's no monitoring dashboard... describe the problem in chat and Claude Code handles it." That works for debugging, but it doesn't work when the system itself is down — you can't ask Claude to diagnose a problem if the pipe is broken. Proposal Add a ncl status command that gives an at-a-glance operational summary without any external dependencies: The data for this is already available: Container liveness: isContainerRunning() in container-runner.ts Last message timestamps: inbound.db → messages_in + outbound.db → messages_out Token expiry: data/v2-sessions/ /claude.json → claudeAiOauth.expiresAt Recent errors: last N lines of logs/nanoclaw.error.log No new infrastructure needed — pure read from existing DBs and files. Why not just improve
nanocoai/nanoclaw issue #3234 reports: Summary ncl groups create --template assigns the new agent group a **bare randomUUID()**, while the --folder path assigns ag-. Since the agent-group id is used verbatim as the OneCLI agent identifier at spawn, a bare UUID beginning with a digit appears to hit exactly the failure described in #2386. This is on main today (v2.1.54), not introduced by #3220 — that PR only moves the line. The two paths | Path | id | File | |---|---|---| | ncl groups create --folder | ag-${randomUUID()} | src/cli/resources/groups.ts:156 | | ncl groups create --template | randomUUID() | src/templates/create-agent.ts:65 (main) /:99 (#3220) | Two other creation paths also prefix — src/modules/agent-to-agent/create-agent.ts:130 and src/modules/permissions/channel-approval.ts:325, both ag-${Date.now()}-…. The template path is the only one that does not. Why the prefix matters The group id becomes the OneCLI identifier directly: 2386 reports OneCLI rejecting a bare-UUID identifier: A v4 UUID satisfies every clause except **start with a letter** — its first hex character is 0-9a-f, so it begins with a digit roughly **62.5%** of the time (10 of
Why it matters
Remote tools fail mysteriously when they start in the wrong directory; operators are blind when health requires the full app; generated identities are brittle when one prefix determines whether the host accepts them. The operator test is whether visible output, retained state and authority still describe the same event after retries, background work or restart.
Current
The primary record was open when captured on 2026-08-13. The tagged-release baseline was v2.1.54 published 2026-08-01T20:46:31Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nanocoai/nanoclaw/pull/3231. Supporting records are https://github.com/nanocoai/nanoclaw/issues/2504 and https://github.com/nanocoai/nanoclaw/issues/3234. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Report effective working directories, keep status independent of the main service path where possible, and validate generated identifiers before they reach host registration. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.