anomalyco / anomalyco/opencode

tui: /export reports failure and drops editor edits when the external editor exits non-zero

Open
#44,299 0 comments 0 reactions 1 assignee View on GitHub

@kommander is already working on this.

Since Aug 23, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

/export writes the transcript file first and then opens it in $EDITOR. If the editor exits non-zero, the promise rejects into the outer catch and the TUI shows "Failed to export session" - even though the export file was already created successfully on disk. Any edits saved in the editor before the non-zero exit are also silently discarded, because the post-editor rewrite (if (result !== undefined) await writeExport(filepath, result)) never runs.

Relevant path in packages/tui/src/routes/session/index.tsx (session.export handler):

  1. await writeExport(filepath, transcript) - file is written
  2. const result = await openEditor({...}) - openEditor rejects on any non-zero editor exit (packages/tui/src/editor.ts: rejects with Editor exited with ... instead of returning)
  3. rejection skips both the rewrite and the success toast, landing in catch -> "Failed to export session"

So the reported outcome is wrong (the export exists), and the user cannot tell whether their file was written or whether their editor edits survived.

Steps to reproduce
  1. Set EDITOR to a command that exits non-zero, e.g. a script containing just exit 1 (or use vim and quit with :cq).
  2. In a TUI session with messages, run /export and confirm the default filename.
  3. Observe the "Failed to export session" error toast.
  4. Check the working directory: session-<id>.md exists and contains the full transcript - the export actually succeeded.
  5. With an editor like vim: make an edit, save, quit via :cq - the exported file still has the pre-edit content; the edit is gone without any warning.
Operating System

Windows 11 (logic is platform-independent)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.