Hook scripts don't initialize or share session state - memory and context externalization non-functional

[Promethean-Pty-Ltd]

Summary

The plugin's hook scripts run as separate Python processes but don't initialize or persist session state between invocations. This means:

1. Session state is never created
2. Context is never tracked (conversation, files, tool outputs)
3. PreCompact externalization fails
4. Memory store is never populated during normal operation

Note: I also encountered hook errors on initial installation (which I understand is a known issue reported by others). These were resolved, but the problems below persist.

Evidence

1. init_rlm.py doesn't initialize session state

The SessionStart hook only creates config files and directories. It doesn't call persistence.init_session() or set up state for subsequent hooks.

2. Hooks run in isolated processes

Each hook runs as a subprocess. When externalize_context.py runs, persistence.current_state and persistence.current_context are both None.

3. PreCompact externalization fails

cd ~/.claude/plugins/cache/rlm-claude-code/rlm-claude-code/0.3.5
.venv/bin/python scripts/externalize_context.py
# Output: {"status": "error", "reason": "Extra data: line 14 column 2 (char 329)"}

The ~/.claude/rlm-externalized/ directory does not exist, confirming this hook has never succeeded.

4. Memory database is empty

The database exists but has no content from normal plugin operation.

5. Agent has no actual REPL

The agents/rlm-orchestrator.md describes Python functions like peek(), search(), recursive_query(), but the spawned agent only has standard Claude Code tools. Is the REPL functionality planned for a future release?

Environment

• Plugin version: 0.3.5
• Platform: macOS
• Python: 3.13 (via plugin .venv)

Questions

1. Is session state sharing between hooks intended to work currently?
2. Is the REPL functionality documented in the agent file currently implemented, or is it planned?

[rand]

Thank you for this thorough analysis! You've identified real architectural constraints.

Responses to your findings:

1. JSON corruption ("Extra data" error)

Fixed in v0.4.1: This was a race condition where concurrent hook processes could corrupt the state file. We now use atomic writes (temp file + rename). Please update to v0.4.3.

2. Hooks run in isolated processes

This is expected behavior - Claude Code runs each hook as a subprocess. The hooks share state via the filesystem (~/.claude/rlm-state/), not in-memory. Each hook:

• Reads state from disk on start
• Modifies in-memory state
• Writes state back to disk

3. Session state initialization

You're correct that init_rlm.py should call persistence.init_session(). Currently it only sets up config. I'll address this.

4. Memory database empty

The memory store is populated when you explicitly use memory functions or when RLM mode activates for complex queries. It's not automatically populated from conversation history (that would require Claude Code to expose conversation content to hooks, which it doesn't).

5. REPL functionality

The REPL functions (peek(), search(), recursive_query()) are available when RLM spawns a subagent via the Task tool. They're not available in the main conversation - they're for the recursive sub-queries that RLM uses internally. The rlm-orchestrator agent has access to these in its sandboxed environment.

Summary

• v0.4.1+ fixes the JSON corruption
• Hooks sharing state via filesystem is by design
• Will improve init_rlm.py to properly initialize session
• Memory/REPL features work during RLM activation, not passive conversation

Would you like me to add documentation clarifying this architecture?