feat(plugin): add session title rename tool

[VooDisss]

Fixes #306

Summary

This change adds a dedicated plugin tool for renaming the active session title and wires it through the existing CodeNomad plugin bridge to the correct OpenCode workspace instance.

The goal is to let the assistant perform the same session title rename operation that already exists in the UI, without introducing a separate metadata store or bundling in the still-unsettled description feature.

Why

Users can already rename sessions manually in the UI, but there was no supported end-to-end conversational path for the assistant to do the same thing.

That mismatch meant the assistant could acknowledge a rename request without having a repo-native implementation path to update the actual session title. This PR closes that gap with the smallest correct change and keeps the scope intentionally limited to title renaming only.

What Changed

1. Added a new rename_session plugin tool in packages/opencode-config/plugin/lib/session.ts.
2. Registered the session tool set in packages/opencode-config/plugin/codenomad.ts.
3. Added a plugin server endpoint in packages/server/src/server/routes/plugin.ts that proxies title updates to the workspace OpenCode instance.
4. Forwarded the current tool execution directory so the rename follows the existing worktree-aware session targeting behavior.
5. Corrected the proxy implementation to use PATCH, matching the real OpenCode SDK session.update contract.

Scope Boundaries

Included:

• Session title rename tool
• Plugin registration
• Server bridge for title updates
• Worktree-aware forwarding via directory context

Not included:

• Description persistence
• Description rendering in the UI
• Session tooltip changes
• Any broader session metadata model changes

Technical Notes

The OpenCode SDK contract for session updates is not POST; it is PATCH /session/{sessionID} with a body containing the updatable fields such as title.

That detail matters because the first implementation path could appear successful while failing to apply the rename if the bridge used the wrong HTTP method. The final implementation aligns the server proxy with the generated SDK contract so the rename is applied by the actual OpenCode session update endpoint.

Files Changed

• packages/opencode-config/plugin/codenomad.ts
• packages/opencode-config/plugin/lib/session.ts
• packages/server/src/server/routes/plugin.ts

Verification

Performed:

1. Verified the generated OpenCode SDK contract for session.update.
2. Confirmed the plugin can call the new bridge endpoint.
3. Confirmed the feature works after switching the proxied request from POST to PATCH.
4. Rebuilt packages/server successfully.

Build note:

• The server build passes.
• The build still emits existing UI/Vite warnings unrelated to this change.

Risks and Follow-up

1. Description handling remains intentionally postponed and should be handled as a separate follow-up once the storage and UX direction is settled.
2. If future session metadata tools are added, they should continue to reuse the same plugin bridge pattern instead of creating parallel storage behavior.

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Understood request: perform a gatekeeper review of the latest PR state for regressions and implementation quality. Assumption: this is a review-only request, so I did not change files.

Gatekeeper Findings

1. Blocking: worktree-scoped renames are likely sent to the wrong OpenCode directory context

   packages/server/src/server/routes/plugin.ts:109-127

   The new plugin bridge forwards the tool's directory as a query parameter:

   params.set("directory", parsed.directory)
   const targetUrl = `http://127.0.0.1:${port}/session/${encodeURIComponent(parsed.sessionID)}?...`

   Existing CodeNomad/OpenCode routing uses x-opencode-directory for directory scoping, not a directory query parameter. The main instance proxy explicitly sets that header, and the background-process completion path does the same:

   • packages/server/src/server/http-server.ts:630-635
   • packages/server/src/background-processes/manager.ts:637-641

   This matters because the PR’s stated goal is worktree-aware session targeting. If OpenCode ignores ?directory=..., the PATCH /session/:sessionID call runs in the default/root directory context. For sessions created in a worktree, that can fail to find the session or update the wrong project context. This is the core path of the feature, so I would not merge until this is fixed.

   Recommended fix: mirror the existing proxy behavior and send the directory as x-opencode-directory, preserving the non-ASCII encoding behavior used elsewhere:

   if (parsed.directory) {
     headers["x-opencode-directory"] = /[^\x00-\x7F]/.test(parsed.directory)
       ? encodeURIComponent(parsed.directory)
       : parsed.directory
   }

   Then remove the unsupported directory query construction unless OpenCode has a documented query contract for this endpoint.

2. Missing regression coverage for the new bridge contract

   packages/server/src/server/routes/plugin.ts:101-140

   This PR adds a new privileged server-to-OpenCode bridge endpoint, but there is no test asserting the proxy method, body, auth header, and directory forwarding behavior. The exact bug above is the kind of regression a small route test would catch. At minimum, add coverage that POST /workspaces/:id/plugin/session/title results in a downstream PATCH /session/:id with { title }, instance authorization, and x-opencode-directory when a directory is supplied.

Better Implementation Notes

• The smallest correct implementation is still fine: a plugin tool plus a server bridge is appropriate for this feature.
• The bridge should follow the same directory-forwarding convention as the existing instance proxy and background-process notification code. Introducing a third ad hoc directory transport (?directory=) is the part that breaks consistency and likely behavior.
• The route currently duplicates low-level fetch/proxy behavior. That is acceptable for a tiny endpoint, but only if it exactly preserves the established auth and directory semantics.

Verification Performed

• Reviewed full PR diff against origin/dev.
• Inspected existing CodeNomad instance proxy and background-process OpenCode call patterns.
• Checked the existing UI rename flow, which uses the worktree client/proxy path rather than a raw query-string directory override.

Verification commands attempted:

• npm run typecheck --workspace @neuralnomads/codenomad failed before checking this PR because local dependencies are incomplete: Cannot find type definition file for 'node'.
• npm run build --workspace @neuralnomads/codenomad failed before building this PR because Rollup’s optional native package is missing locally: Cannot find module @rollup/rollup-darwin-arm64.

These verification failures appear to be local dependency-install issues, not direct evidence about the PR code.

Verdict

Request changes. The feature shape is good, but the directory forwarding bug is a likely functional regression for the stated worktree-aware requirement and should block merge.

--
Yours,
CodeNomadBot