# Bug/UX: Custom chat names are not persisted to the server and are lost on `/resume`

[ovistoica]

Summary

When a user renames a chat with eca-chat-rename (C-c C-S-r), the new name is
stored only in the Emacs buffer as a client-side buffer-local variable. It is
never sent to the server. As a result:

• /resume lists chats by the server's auto-generated title (e.g.
  "Fixing eca API key config"), ignoring any user-assigned name
• After /resume opens the chat in a new buffer, the custom name is gone entirely
• The server's remote API (GET /chats) also returns only the original
  auto-generated title

Expected behavior: Renaming a chat should persist the new name so that
/resume (and any other chat listing) reflects it.

---

Steps to Reproduce

1. Start an ECA session and send a prompt — the chat gets an auto-generated title
   (e.g. "Debugging API endpoint")
2. Rename the chat: C-c C-S-r → type "My important investigation" → RET
3. Observe: the tab, header line, and workspaces tree all show the new name ✅
4. Kill the ECA session or start a new one
5. In the new session, type /resume to list available chats
6. Observe: the chat appears as "Debugging API endpoint" — the custom name is
   completely absent ❌
7. Run /resume N to resume that chat
8. Observe: the opened buffer has no custom title — the rename is permanently
   lost ❌

---

Root Cause Analysis

The rename is purely client-side and ephemeral

eca-chat-rename only writes to a buffer-local variable:

;; eca-chat.el
(defun eca-chat-rename ()
  "Rename last visited chat to a custom NEW-NAME."
  (interactive)
  (let ((new-name (read-string "Inform the new chat title: ")))
    (eca-assert-session-running (eca-session))
    (with-current-buffer (eca-chat--get-last-buffer (eca-session))
      (setq eca-chat--custom-title new-name))))   ; ← buffer-local only, no RPC call

There is no chat/rename RPC method, no chat/setTitle notification, nothing.
The server is never informed of the new name.

The server has a single title field, set only once

The server DB schema (db.clj) has exactly one field for the chat name:

:chats {"<chat-id>" {:id :string
                     :title (or :string nil)   ; the only title field
                     ...}}

This field is populated once — asynchronously on the first prompt, via a background
LLM call using the chatTitle prompt. After that it is never updated by any
user-facing mechanism.

/resume reads :title from the server DB

The /resume command in commands.clj builds its chat listing using only
(:title chat):

;; features/commands.clj — /resume listing
(format "%s - %s - %s\n"
        (inc (.indexOf ^PersistentVector chats-ids chat-id))
        (shared/ms->presentable-date (:created-at chat) "dd/MM/yyyy HH:mm")
        (or (:title chat)                             ; ← server :title only
            (format "No chat title (%s user messages)" msgs-count)))

It has no knowledge of eca-chat--custom-title.

The display priority on the client hides the problem

eca-chat-title correctly prioritises the custom name over the server name:

;; eca-chat.el
(defun eca-chat-title ()
  (cond
   (eca-chat--custom-title ...)   ; custom wins if set
   (eca-chat--title ...)          ; server title fallback
   (t "Empty chat")))

This makes the rename appear to work perfectly within the active buffer session.
The illusion breaks the moment the buffer is killed — because eca-chat--custom-title
dies with it.

Full disconnect diagram

User: C-c C-S-r → "My important investigation"
          │
          ▼
  eca-chat--custom-title = "My important investigation"   (buffer-local)
  [NO server call, NO RPC, NO persistence]
          │
          ▼
  Tab / header / tree show "My important investigation"   ✅ (looks correct)

  [Session ends / buffer killed]
          │
          ▼
  eca-chat--custom-title = nil                            (gone forever)
  Server DB: :title = "Fixing eca API key config"         (unchanged)

  User: /resume
          │
          ▼
  Server sends: "3 - 30/03/2026 09:25 - Fixing eca API key config"  ❌

---

Proposed Fix

Option A — Persist the custom title server-side (recommended)

Add a chat/rename (or chat/setTitle) RPC method on the server that updates
[:chats chat-id :title] and flushes the cache.

Server (handlers.clj):

(defn chat-rename [{:keys [db* metrics]} {:keys [chat-id title]}]
  (when (get-in @db* [:chats chat-id])
    (swap! db* assoc-in [:chats chat-id :title] title)
    (db/update-workspaces-cache! @db* metrics)
    {}))

Server (server.clj):

"chat/rename" (handlers/chat-rename components params)

Client (eca-chat.el) — eca-chat-rename:

(defun eca-chat-rename ()
  "Rename the current chat, persisting the new name to the server."
  (interactive)
  (let ((new-name (read-string "New chat title: ")))
    (eca-assert-session-running (eca-session))
    (with-current-buffer (eca-chat--get-last-buffer (eca-session))
      ;; Update locally for immediate display
      (setq eca-chat--custom-title new-name)
      ;; Persist to server so /resume and other sessions see it
      (eca-api-notify (eca-session)
                      :method "chat/rename"
                      :params (list :chatId eca-chat--id
                                    :title new-name)))))

Client — on chat/contentReceived "metadata" frame:

Since lifecycle/send-content! already sends {:type :metadata :title ...} to the
client after the server writes the title, the client could also update
eca-chat--title (not eca-chat--custom-title) to keep the server and client
display names in sync:

("metadata"
 (unless parent-tool-call-id
   (setq-local eca-chat--title (plist-get content :title))))

This is already done — it sets eca-chat--title. With Option A the rename would
update :title on the server, which would then push a "metadata" frame back,
which would set eca-chat--title on the client. At that point
eca-chat--custom-title could be cleared (the server is now the source of truth):

("metadata"
 (unless parent-tool-call-id
   (let ((title (plist-get content :title)))
     (setq-local eca-chat--title title)
     ;; If server confirmed our rename, the custom title is now redundant
     (when (string= title eca-chat--custom-title)
       (setq-local eca-chat--custom-title nil)))))

This is optional — keeping eca-chat--custom-title as a local display override
is also fine.

Option B — Two-field schema: auto-title + user-title (alternative)

Keep the LLM-generated title in :title (untouched) and add a separate
:custom-title field that the rename operation writes:

;; db.clj
:chats {"<chat-id>" {:title (or :string nil)         ; LLM-generated
                     :custom-title (or :string nil)  ; user-assigned
                     ...}}

/resume and the remote API would then display (or :custom-title :title).

Advantage: The original auto-generated title is never destroyed, which can be
useful for debugging or if the user wants to revert.

Disadvantage: More schema surface and slightly more logic everywhere a title is
read.

---

Impact

Feature	Current behaviour	With fix
/resume listing	Shows LLM-generated title	Shows user-assigned name
After /resume, new buffer	eca-chat--custom-title is nil (name lost)	Server sends correct title via "metadata" frame
Remote HTTP API (GET /chats)	Returns LLM-generated title	Returns user-assigned name
Tab-line / header in active buffer	Shows custom name correctly ✅	No change
Server cache (db.transit.json)	Only :title saved	:title updated by rename and saved
Name survives ECA server restart	❌ No (custom title is gone)	✅ Yes (written to disk cache)

---

Files to Change

Server

File	Change
src/eca/handlers.clj	Add chat-rename handler
src/eca/server.clj	Register "chat/rename" in the dispatch table
src/eca/db.clj	Optional: add :custom-title field to schema doc (Option B only)

Client (eca-emacs)

File	Change
eca-chat.el eca-chat-rename	Add eca-api-notify call after setting eca-chat--custom-title

That is the minimal fix — two changed files, one new server handler, one added
eca-api-notify call in the client.

---

Classification

This is could be either a bug or ux improvement in the rename feature: eca-chat-rename presents itself as
persisting a name change (C-c C-S-r with an explicit "Inform the new chat title"
prompt) but silently discards the change the moment the buffer is killed. A user
who renames a chat has a reasonable expectation that the name will be remembered.

[ovistoica]

@ericdallo If this looks valid and is a good first issue, I could take this up myself

[ericdallo]

@ovistoica yeah the thing is custom chat names are only client side, I think we would need to evolve the protocol to support customizing chats somehow, not that trivial, but LMK if you wanna take a look.
I wonder if we wanna a generic chat/rename message or a generic one for change chat things, the rename may be the best for now tho

[ovistoica]

@ericdallo related to generic change chat things I have some more thoughts, but not necessarily related to chat rename. Also please let me know if this is going off a tangent or it should be its own issue:

chat/update could also be used to add labels to specific messages. This has implications for chat compaction too. I will elaborate on the two below:

Compaction

Currently compaction in emacs will replace the entire chat history. This is not ideal because the user loses a lot of context. Ideally, compaction should work like this: Add the new compaction message to the chat log, and add a label to it. Pi calls the label a tombstone . The full chat history still exists but the agent doesn't see past this tombstone.

Benefits: If I want to go in a different direction with the chat, I can fork and rollback to whatever message I care about in the full history of the conversation.

Currently: If I compact the chat I lose all of that history, not to mention that now all of the potential for hitting token caches is gone.

Labeling

If you have a chat/update protocol method you can use it to label specific user/assistant messages from the chat history. This is very useful for forking/resuming from that point in another conversation.

Example: Say I want to do some frontend work in my project:

1. I start a chat
2. Load the skills the agent needs for that work
3. I give some initial context into the project
4. I label the last message here My Project Frontend Ready Agent

Now, a week from now, I can have other work needed on frontend for my project so I can resume the chat or fork it directly from this label (or tag if we go with git terminology). The benefit is I still get the promp caching and if you are using anthropic, caching really pays off.

---

I listed the two potential examples from above as usecases that I really want that could be achieved with a chat/update protocol to give the idea more merit. Note, the name chat/update might already be taken, I'm not fully sure.

Please let me know if I should create separate issues for them

[ericdallo]

@ovistoica

If I compact the chat I lose all of that history, not to mention that now all of the potential for hitting token caches is gone.

I can see tombstones being useful, we could support that, but I wanna understand some things:

• tombstones change nothing to LLM right? in the end we won't send the previous chat, it's more visually for user
• ECA doesn't clean the chat when compacting so it's still visible, right? of course if you resume the chat you won't get that or fork it, that's why I see tombstones being useful, we could evolve compact to behave like that.

Label

Yeah, I see label as a improvement of fork, if we have the ability to fork from any message, would this still be needed?

For both things, let's have a issue for each one so we can discuss it separated and precisely.
I don't think discussing the protocol right now makes sense, I like to think in the feature and UX as primary things to then think how the protocol should evolve to support those, but yeah, chat/update doesn't sound bad for now

BTW I'm working on prompt caching improvements for anthropic, making possible to cache parts of the system prompt instead of whole system prompt (which might be invalidated with any change).

[ovistoica]

I'll open separate issues, but just to answer your questions:

tombstones change nothing to LLM right? in the end we won't send the previous chat, it's more visually for user

Yes, tombstones change nothing to the LLM. The LLM's visibility into the context stops at the tombstone which most likely is a compaction message. The utility is purely for the user to see the pre-compaction history and having the possibility to fork out from any of those points

ECA doesn't clean the chat when compacting so it's still visible, right? of course if you resume the chat you won't get that or fork it, that's why I see tombstones being useful, we could evolve compact to behave like that.

Yes, if, in the current client session, compact, then in the buffer (using emacs for example) you still see the chat history, but the loss is when you resume. Since on the server, once compaction happens, the prior context is lost, the only place where that is kept is buffer local

Yeah, I see label as a improvement of fork, if we have the ability to fork from any message, would this still be needed?

I was about to open an issue about this, let me know if needed. I would love to have fork from any point. Flow /fork -> eca-chat-timeline pops up, and I can choose the message from which to fork. The improvement would be that the label is also searchable as a convenience.

Currently the flow is: /fork -> go to new chat-> call eca-chat-timeline -> select my desired start point -> revert chat (the fork) to that point