Greptile Summary

This PR adds a /set_topic_name command that lets Telegram users rename their topic's session label via chat. The new commands-topic-name.ts handler wires into the existing command-dispatch chain and updates the session label via sessions.patch. Error handling is generic (logging details internally), and the command is correctly gated to authorized senders.

Key observations:

• Surface check ordering (logic): The !parsed.ok usage-error guard fires before isTelegramSurface, so a non-Telegram user who omits the name argument sees "Usage: /set_topic_name <name>" rather than "only works for Telegram topics" — an incorrect hint for a platform where the command can never succeed. The surface check should move above the usage check.
• threadId validated but unused (logic): threadId is retrieved and checked for presence (lines 54–59) but is never forwarded to callGateway. This is fine if each Telegram topic maps to a unique sessionKey, but should be explicitly verified — if session keys are not thread-scoped, the patch could silently update the wrong label.
• The registry declaration (captureRemaining: true) is consistent with the manual regex parsing in the handler; both serve their respective roles (documentation vs. runtime).

Confidence Score: 2/5

• Not safe to merge yet — there are unresolved logic issues in the core handler that need to be addressed first.
• Two new logic issues were identified: incorrect check ordering that gives misleading feedback to non-Telegram users, and threadId being validated but never passed to the gateway (creating a risk of silently patching the wrong session if session keys are not thread-scoped). Combined with open items from prior review rounds that are still present in the code, the handler needs further iteration before it is production-ready.
• src/auto-reply/reply/commands-topic-name.ts requires the most attention — both new issues are in this file.

This is a comment left during a code review.
Path: src/auto-reply/reply/commands-topic-name.ts
Line: 45-53

Comment:
**Surface check comes after args validation**

The `!parsed.ok` guard (line 45) runs before `isTelegramSurface` (line 48). This means an authorized user on a non-Telegram surface who types `/set_topic_name` with no name argument will receive `"Usage: /set_topic_name <name>"` instead of `"⚙️ /set_topic_name only works for Telegram topics."` — directing them to fix their usage for a command that can never work on their surface regardless.

The `isTelegramSurface` check should come before the usage-error check:

```typescript
  if (!parsed.ok) {
    return { shouldContinue: false, reply: { text: parsed.error } };
  }
  if (!isTelegramSurface(params)) {
    return {
      shouldContinue: false,
      reply: { text: "⚙️ /set_topic_name only works for Telegram topics." },
    };
  }
```

should be reordered to:

```typescript
  if (!isTelegramSurface(params)) {
    return {
      shouldContinue: false,
      reply: { text: "⚙️ /set_topic_name only works for Telegram topics." },
    };
  }
  if (!parsed.ok) {
    return { shouldContinue: false, reply: { text: parsed.error } };
  }
```

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

---

This is a comment left during a code review.
Path: src/auto-reply/reply/commands-topic-name.ts
Line: 54-78

Comment:
**`threadId` validated but never forwarded to gateway**

`threadId` is extracted and validated on lines 54–59 to ensure the command only runs inside a Telegram topic thread, but it is never included in the `callGateway` payload — only `params.sessionKey` and `label` are sent.

If `sessions.patch` uses `sessionKey` alone and each Telegram topic always maps to a unique session key, this is harmless. However, if multiple topics share the same session key (or if the gateway needs `threadId` to scope which thread's label to update), this silently patches the wrong label without any error.

Please confirm that `sessions.patch` with `sessionKey` alone is sufficient to uniquely identify the correct Telegram topic, or add `threadId` to the gateway payload if the API requires it for disambiguation.

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

_{Last reviewed commit: 41137be}

oops. nice AI review :)

will make changes in a sec

💡 Codex Review

https://github.com/openclaw/openclaw/blob/cdaf0c45397649f3f7facece3079709d01b91ea9/docs/.generated/config-baseline.json#L2
Restore canonical config baseline formatting

Reformatting this generated file changed key ordering and array layout from the writer’s canonical output (renderConfigDocBaselineStatefile uses JSON.stringify(..., null, 2)), so pnpm config:docs:check will now report perpetual drift even when the config schema is unchanged. In practice this breaks the config-docs drift validation workflow (.github/workflows/workflow-sanity.yml job config-docs-drift) and forces unnecessary regeneration noise on future changes.

@Lukavyi sounds good lol i didn't clean this up fast enough / got sidetracked.

Thanks!