The Work Item Was the Same, but the Chat Names Were Different
Tomohiro Iida · Published August 21, 2026 · Updated August 21, 2026
When ChatGPT, Claude Code, and Codex are used on the same development work, time can shift from implementation to finding which conversation is the continuation. Netsujo encountered this when tool-specific chat names made successor chats, stopped work, pull requests, and current evidence harder to connect.
Key takeaways
- At handoff, enforce TARGET_CHAT_NAME = SOURCE_CHAT_NAME.
- Do not treat the shared name as a unique identifier; add WORK_ITEM_ID and PREDECESSOR_CHAT.
- Carry the live repository, pull request, branch, CURRENT_HEAD_SHA, status, authority, and completion criteria.
- If the destination tool cannot rename a chat, record the capability as unavailable or unverified instead of reporting PASS.
- For high-risk work, make name and identity checks a pre-mutation gate.
Incident: the same work item had different names across tools. False assumption: the conversation body was enough to identify the work. Root cause: there was no shared cross-tool identity contract. Immediate fix: exact name equality. System fix: pair the name with stable work identity and live evidence.
A small naming mismatch broke the visible lineage of work
A different chat name does not directly change code. The observed cost was extra reading and comparison before a person could determine which conversation was current. As the number of tools and continuation chats increased, the sidebar stopped functioning as a reliable index.
- Requirements and acceptance criteria are prepared in ChatGPT.
- Implementation is handed to Claude Code.
- Independent review is handed to Codex.
- A CI failure is investigated in another conversation.
- A long conversation is stopped and continued in a new one.
- Work pauses for owner authorization and resumes after main has changed.
If every tool invents a new summary name, the person must open each chat and reconstruct the repository, pull request, SHA, remaining work, and permission boundary. This makes stale restarts, duplicated investigation, and mixed evidence harder to detect early.
Treat the chat name as a human index, not a database key
People see the sidebar name before they see a UUID or internal session ID. The name is therefore useful for grouping, search, and rapid comparison across tools. It should be stable across the handoff, but it should not carry every changing field.
Required equality: TARGET_CHAT_NAME = SOURCE_CHAT_NAME. Do not translate, abbreviate, “improve,” or append a tool or role name only at the destination.
Use three identity layers
| Layer | Purpose | Example |
|---|---|---|
| Human-readable chat name | Common label for sidebar grouping and search | Owner approval design review |
| Stable work-item ID | Distinguish same-name chats and preserve identity across tools | work-20260821-owner-qc |
| Live execution evidence | Determine what may be changed now | PR #1280, head SHA, BLOCKED |
The same name is not a unique identifier. A continuation chat can intentionally reuse the name, and one work item can branch into multiple lanes. Keep the readable label, stable ID, predecessor, and current Git state as separate fields.
Fix the handoff header before the narrative
| Field | Function |
|---|---|
| SOURCE_CHAT_NAME | The exact source-side name |
| TARGET_CHAT_NAME | The name required at the destination |
| CHAT_NAME_MATCH | PASS only after exact equality is verified |
| WORK_ITEM_ID | Stable identity across tools and continuation chats |
| PREDECESSOR_CHAT | Reference to the immediately preceding conversation |
| HANDOFF_SEQUENCE | Order of continuation when names are intentionally reused |
| REPOSITORY / PR / BRANCH | Current Git target |
| CURRENT_HEAD_SHA / BASE_SHA | Exact state assumed by the handoff |
| CURRENT_STATUS / BLOCKERS | PASS, FAIL, BLOCKED, or UNVERIFIED |
| AUTHORIZED_ACTIONS | Operations the destination may perform |
| PROHIBITED_ACTIONS | Merge, deploy, force push, or other forbidden operations |
| COMPLETION_CRITERIA | Evidence required before the work can be called complete |
Block mutation when the identity contract is not satisfied
A written rule is weak if the destination starts editing, pushing, reviewing, merging, or deploying before checking it. For higher-risk work, name and work identity become a pre-mutation gate. Metadata correction and read-only state inspection may continue; mutation does not.
Fail-closed rule: when TARGET_CHAT_NAME differs from SOURCE_CHAT_NAME, record a metadata blocker and perform no mutation. When chat renaming is unavailable, record CHAT_RENAME_CAPABILITY = NOT_AVAILABLE and CHAT_NAME_MATCH = UNVERIFIED.
Carry current state, not only a conversation summary
A sentence such as “CI is green” is insufficient. It does not identify the workflow, run, subject SHA, required-check status, skipped checks, or whether the pull request head moved afterward. A handoff needs both narrative and state evidence.
- Narrative
- Why the work exists, what happened, which decision was adopted, and what is intentionally out of scope.
- State Evidence
- Repository, pull request, exact head SHA, CI run, review, authorization, blocker, prohibited operations, and next action.
Common failure modes
- The destination improves the name
- A clearer destination-only title breaks the visible lineage. Rename the entire chain only when every reference can be updated together.
- The name receives a “Codex” or “Claude” suffix
- Tool and role belong in EXECUTOR and ROLE fields. Otherwise the chat name changes every time the executor changes.
- The pull request number becomes the whole name
- The purpose becomes unclear and the title becomes stale when work moves to a successor pull request.
- Same name is assumed to mean same state
- Exact name equality only suggests shared lineage. The branch, head SHA, and status still require a live check.
- The stopped predecessor is deleted
- The predecessor contains assumptions and decisions. Close it with a terminal state and preserve the link instead of erasing the record.
Scale the contract with risk
| Operating level | Minimum fields |
|---|---|
| Low-risk solo work | Exact name, repository, pull request, successor reference |
| Standard multi-agent work | Name, WORK_ITEM_ID, predecessor, exact SHA, state, prohibited actions, completion criteria |
| Authentication, billing, data, database, or production work | Standard fields plus exact-SHA authorization, owner final QC, evidence ledger, pre-mutation gate, production verification, and terminal audit record |
Reusable handoff contract
- HANDOFF_CONTRACT_VERSION: 1
- SOURCE_CHAT_NAME and TARGET_CHAT_NAME: exact same value
- CHAT_NAME_MATCH: PASS only after verification
- WORK_ITEM_ID and PREDECESSOR_CHAT
- HANDOFF_SEQUENCE, EXECUTOR, and ROLE
- REPOSITORY, PR, BRANCH, CURRENT_HEAD_SHA, and BASE_SHA
- CURRENT_STATUS and BLOCKERS
- AUTHORIZED_ACTIONS and PROHIBITED_ACTIONS
- NEXT_ACTION and COMPLETION_CRITERIA
- FINAL_REPORT with final SHA, tests, CI, merge, production, and remaining blockers
Measure whether the rule reduces operational waste
- Time spent locating the successor conversation.
- Duplicated investigations assigned to another agent.
- Stale conversations blocked before mutation.
- Pull request, SHA, or authorization-target mix-ups.
- Ability to distinguish stopped and active work.
- Ability to trace the final report back through predecessor chats.
The rule has been introduced, but long-term quantitative impact is not yet established. The reduction in duplicate investigation and handoff errors still needs to be measured from operating logs.
Remaining risks
- Tools differ in their ability to rename chats or expose stable session references.
- Multiple chats can share the same visible name.
- A handoff summary can be stale even when the name is correct.
- The repository can advance after the handoff was written.
- Another agent can update the same pull request after identity was checked.
- An agent can self-report CHAT_NAME_MATCH = PASS without the interface being independently verified.
Frequently asked questions
Does an identical chat name prevent handoff incidents?
No. The name is a human index. A stable work-item ID, predecessor, repository, pull request, current head SHA, and authority boundary are also required.
Should the pull request number be part of the chat name?
Do not use the pull request number as the whole name. Keep the name focused on the work purpose and record the pull request as state evidence, because the work may move to a successor pull request.
What if Claude Code or Codex cannot rename the chat?
Display the canonical name and work-item ID at the top of the handoff, record the rename capability as unavailable, and do not claim name equality was verified. Continuing high-risk mutation becomes a separate owner decision.
Can one long chat remove the need for handoffs?
Long conversations accumulate stale assumptions and state changes. When a continuation is created, preserve the name, identify the predecessor, and re-check the live repository and pull request state.
View the complete AI Agent Development Incident Log
Move repeated human checks into a Controller, Evidence Ledger, and Gate
Separate parallel implementation and sequential integration
Netsujo can help separate work identity, Git state, CI evidence, authority, and production verification so cross-agent handoffs do not depend on rereading conversations.
Design a verifiable multi-agent handoff workflow