Greptile Summary

This PR scopes each Android device to its own session by deriving a unique key (agent:main:node-<shortDeviceId>) from the device identity, replacing the shared hardcoded "agent:main:main" key that caused multiple nodes on the same gateway to share conversation history. The gateway-side session machinery is unchanged; only the Android client changes how it picks its default session key.

Changes made:

• NodeRuntime.kt: Adds generateNodeSessionKey() which reads the device's identity, takes the first 8 hex chars of its ID, and returns agent:main:node-<shortDeviceId>. This is used as the initial value of _mainSessionKey and as the reset target on disconnect. The key format starts with "agent:" so isCanonicalMainSessionKey (in SessionKey.kt) correctly treats it as canonical.
• NodeRuntime.kt: Applies the session key immediately at ChatController construction via .also { it.applyMainSessionKey(...) }, fixing a gap where the operator-session ChatController was initialised before the key was set.
• ChatController.kt: Removes the guard if (_sessionKey.value != "main") return from applyMainSessionKey, because the default key is no longer the literal "main". However, this removal also strips the protection against overriding a user-switched session on reconnect — see inline comment.

Issues found:

• P1 (logic) — Removing the guard in ChatController.applyMainSessionKey regresses session-switch persistence: a user who switches to a non-default session and then experiences a connection drop will have their active session silently reset to the device default on reconnect.
• P2 (style) — Using only 8 hex characters of the device ID gives a 32-bit namespace; consider increasing to 12–16 to avoid collisions in larger gateway deployments.

Confidence Score: 3/5

• The core device-isolation fix is correct, but removing the session-switch guard in ChatController introduces a regression that disrupts users who manually navigate to non-default sessions during a connection blip.
• The primary goal (per-device session isolation) is achieved correctly and the canonical-key detection works as expected. However, removing the if (_sessionKey.value != "main") return guard breaks session-switch persistence across reconnects — a real user-facing regression that affects anyone using the session-switching feature. That warrants holding at 3 until the guard is replaced with an equivalent that handles the new non-literal default key. The short device-ID prefix is a lower-priority style issue.
• apps/android/app/src/main/java/ai/openclaw/app/chat/ChatController.kt — the applyMainSessionKey function needs a replacement guard to preserve manually-switched sessions across reconnects.

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/chat/ChatController.kt
Line: 81-87

Comment:
**Removed guard breaks session-switch persistence across reconnects**

The old guard `if (_sessionKey.value != "main") return` prevented `applyMainSessionKey` from overriding a session the user had explicitly selected via `switchSession`. Removing it means: if a user switches to a non-default session (e.g. `"work"`) and the gateway connection drops and reconnects, `applyMainSessionKey` will be called again with `"agent:main:node-XXXXXXXX"` and forcibly reset their active session back to the device default.

The guard was removed because the default key is no longer the literal `"main"` — it's the device-specific `generateNodeSessionKey()` value. The fix is to track the canonical default key inside `ChatController` and only override when the current session is still at that default:

```kotlin
fun applyMainSessionKey(mainSessionKey: String) {
    val trimmed = mainSessionKey.trim()
    if (trimmed.isEmpty()) return
    if (_sessionKey.value == trimmed) return
    // Only override if we're still on whatever key was last set as the "main" key,
    // i.e. the user has not manually switched away to a different session.
    if (_sessionKey.value != _lastAppliedMainKey) return
    _lastAppliedMainKey = trimmed
    _sessionKey.value = trimmed
    scope.launch { bootstrap(forceHealth = true, refreshSessions = true) }
}
```
where `_lastAppliedMainKey` is initialized to `"main"` (matching `_sessionKey`'s initial value) and updated in `load()` as well.

Without this, any user who is actively viewing an older session when a connection blip occurs will be silently redirected back to the node-default session.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/NodeRuntime.kt
Line: 196-200

Comment:
**Short device-ID prefix may collide in larger deployments**

`deviceId` is derived from a SHA-256 hash (`sha256Hex` in `DeviceIdentityStore`). Taking only the first 8 hex characters yields a 32-bit namespace (~4 billion combinations). In a small household this is negligible, but at scale — or if many nodes register against the same gateway — two devices could share the same prefix and end up in the same session, reproducing the exact bug this PR is fixing.

Consider increasing the prefix length to at least 12–16 hex characters to give a 48–64 bit namespace, which is effectively collision-free in any realistic deployment:

```suggestion
    val shortDeviceId = deviceId.take(12)
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "[feat]Multiple nodes session context iso..." | Re-trigger Greptile}

How about letting users create new sessions or defining the ID themselves? I'm specifically thinking about how to deal with this in the Wear OS PR. People will want to share the same session with the app or use their own session, or have a mixture of both.

I think the solution should be more advanced, but this is a great start to separate this!

I personally still think the android app is a mixture of a node and a channel/provider. Sensors etc are definitely a node capability, but the chat works more like a channel/provider like Telegram or WhatsApp are, and could offer similar ways to create chats/groups/threads.

How about letting users create new sessions or defining the ID themselves? I'm specifically thinking about how to deal with this in the Wear OS PR. People will want to share the same session with the app or use their own session, or have a mixture of both.

I think the solution should be more advanced, but this is a great start to separate this!

I personally still think the android app is a mixture of a node and a channel/provider. Sensors etc are definitely a node capability, but the chat works more like a channel/provider like Telegram or WhatsApp are, and could offer similar ways to create chats/groups/threads.

@sibbl I fully agree with your judgment that the solution should be more advanced and that Android applications mix Node and Channel responsibilities. The current change is to lay the foundation and eliminate implicit entanglement in the conversation.
On this basis, we can gradually support:

1. User defined session ID and creation strategy
2. Mixed mode of multi device sharing/independent sessions

In addition, the current Android application will display all conversation lists for users to choose from. Can this design meet the requirements you mentioned People will want to share the same session with the app or use their own session.

But I'm not sure how to interact with users on the WearOS screen and display a list of all sessions?

@lixuankai yep, the foundation is what we need. Just sharing my thoughts here, as my Wear OS PR has been open for a while and I watch new PRs since I need to also migrate them over until my PR is reviewed.

But I'm not sure how to interact with users on the WearOS screen and display a list of all sessions?

As of now, the selected session can be changed with a swipe and 2 taps.
However, in my daily usage I see that I may want to have multiple sessions - like a fast one with a smaller model (like setting up reminders etc) and a larger one for more complex stuff (e.g. for doing research on the go). Maybe it may make sense to allow users to pin favorite sessions and be able to swipe between them easily.

However, this depends heavily on where we want to get to with the Android app and its session management. Will it just have one session per node? Per device? Will users be able to quickly create new sessions? Can users even switch between agents? Lots of questions from a user's perspective, which are already solved on channel/provider level where I can configure which agents match which e.g. telegram group etc.

@obviyus please check , thank you

I think Android should default to a private per-device chat session, with shared sessions exposed explicitly as selectable threads instead of implicitly inheriting the gateway main session. That keeps the UX predictable, avoids cross-device context bleed by default, and gives Wear OS / multi-device follow-up work a clean base: one deterministic device-owned default session, optional shared sessions by user choice.

Landed on main.

• Landed source commit: c4dd390
• Merge commit: f0a57fa

Thanks @lixuankai.