Devin plugin hook cannot discover cli-next sessions.db

[jijiamoer]

Describe the bug

The official nowledge-mem Devin plugin v0.1.0 loads successfully, but its lifecycle command exits with code 1 and does not create a Thread on Devin Next:

nmem --json t sync --from devin --hook-stdin --apply

The same session is discovered correctly when cli-next/sessions.db is passed explicitly. This appears to be a default Devin session discovery issue on the tested devin-next build. The plugin hook exposes it because its command does not pass an explicit --session-dir, but the same session is also not found by an ordinary --session-id lookup without --session-dir. The failure remains reproducible after the session is fully persisted, so transient lifecycle timing is not required to explain it.

To Reproduce

Environment:

• macOS 26.5.1
• devin-next 3000.4.1025 (7e8e528a)
• bundled nmem 0.10.66
• nowledge-mem plugin v0.1.0 installed with devin plugins install --local

Steps:

1. Install the official plugin:

   devin plugins install --local nowledge-co/community#nowledge-mem-devin-plugin

2. Start a new Devin Next session and complete one user/assistant turn.

3. Observe that the official Stop hook runs but exits with code 1. No devin-cli-<session-id> Thread is created.

4. After Devin has fully saved the session, replay a Stop payload without --apply:

   printf '%s' '{"hook_event_name":"Stop","session_id":"<session-id>","prompt_id":"post-save-control","stop_hook_active":false}' \
     | nmem --json t sync --from devin --hook-stdin

   Result:

   {
     "status": "error",
     "client": "devin",
     "project_path": "*",
     "results": [],
     "error": "No devin sessions found for project: *",
     "hint": null
   }

5. Run the equivalent preview with the database and session ID explicit:

   nmem --json t sync \
     --from devin \
     --session-dir ~/.local/share/devin/cli-next/sessions.db \
     --session-id <session-id>

   This succeeds with status: success, action: ready, the expected message count, and the expected devin-cli-<session-id> Thread ID.

A post-persistence replay produces the same discovery failure, while explicit database selection succeeds for the same session.

Expected behavior

For the tested devin-next installation, the plugin should be able to import the session identified by the hook payload's session_id without requiring the user to override the plugin command manually. This could be addressed either in session discovery or by having the integration pass the session location appropriate to its runtime.

The successful explicit-database control does not require a retry or delay.

Screenshots

Not applicable. The command output and control result above reproduce the issue.

Additional context

• Manual targeted imports, repeated idempotent imports, appends, and post-compaction appends all work when --session-dir and --session-id are explicit.
• The plugin's Stop and SessionEnd paths did not create a Thread in this test.
• The competing custom synchronizer was stopped during the plugin test, so there was no concurrent writer.
• No new Space was used and no distillation was requested.

[jijiamoer]

Additional controlled diagnostics narrow this down further: this does not appear to be specific to the --hook-stdin branch.

On the tested installation, Devin session databases exist at both of these locations:

• ~/.local/share/devin/cli/sessions.db
• ~/.local/share/devin/cli-next/sessions.db

Using a fully persisted session that exists in the cli-next database but not in the cli database:

nmem --json t sync --from devin --session-id <cli-next-session-id>

returns the same result even without --hook-stdin:

No devin sessions found for project: *

The explicit database form succeeds for that same session:

nmem --json t sync --from devin \
  --session-dir ~/.local/share/devin/cli-next/sessions.db \
  --session-id <cli-next-session-id>

Additional controls:

• nmem --json t sync --from devin --limit 1 reports its selected file as ~/.local/share/devin/cli/sessions.db.
• A session that exists in cli/sessions.db is found successfully by ordinary --session-id.
• Passing that same cli session through --hook-stdin exits successfully (0).
• The tested session count is 0 in the cli database and 1 in the cli-next database.

This suggests the primary issue on this installation is that default Devin database discovery selects cli/sessions.db but does not also discover the session stored in cli-next/sessions.db. The hook exposes the issue because the plugin command does not provide an explicit --session-dir.

One possible fix is for discovery to include the applicable Devin session database locations and resolve the hook payloads session_id across them. Another is for the plugin integration to pass the session directory appropriate to its current runtime. The post-persistence control shows that lifecycle timing is not needed to explain this reproduction.