What would you like to be added?
The prompt input's external editor action (Ctrl+X / open input in external editor) should respect the editor selected through /editor / general.preferredEditor.
Current behavior: /editor sets general.preferredEditor, but the prompt input external editor path only checks $VISUAL, $EDITOR, and then a platform fallback. As a result, users can select an editor in Qwen Code and still see Ctrl+X open a different editor.
Expected behavior: when opening the prompt input in an external editor, prefer general.preferredEditor first. If it is not set, fall back to $VISUAL, then $EDITOR, then the existing platform fallback.
Why is this needed?
This makes /editor behave consistently with what users expect from an external editor preference. Without it, the setting appears to work in some places but not in the prompt editor flow, which is confusing and makes the feature feel unreliable.
Additional context
A possible implementation direction is to pass the resolved general.preferredEditor into the prompt input's external-editor path, or share the existing editor resolution logic used elsewhere. GUI editors need wait flags or wait-capable commands so Qwen Code blocks until the user saves and closes the editor, for example code --wait or zed --wait.
中文
希望增加什么？
prompt 输入框的外部编辑器操作（Ctrl+X / 在外部编辑器中打开输入）应该遵循 /editor / general.preferredEditor 中选择的编辑器。
现状：/editor 会设置 general.preferredEditor，但 prompt 输入框的外部编辑器路径只读取 $VISUAL、$EDITOR，然后使用平台 fallback。因此用户在 Qwen Code 中选择了编辑器后，Ctrl+X 仍可能打开另一个编辑器。
期望：打开 prompt 输入内容的外部编辑器时，优先使用 general.preferredEditor。如果未设置，再回退到 $VISUAL、$EDITOR，最后使用现有平台 fallback。
为什么需要？
这能让 /editor 的行为符合用户对“外部编辑器首选项”的预期。否则该设置在部分场景生效、在 prompt 编辑器流程中不生效，会让用户困惑，也让功能显得不一致。
其他上下文
一种可能实现方向是把解析后的 general.preferredEditor 传入 prompt 输入框的外部编辑器路径，或者复用其他地方已有的编辑器解析逻辑。GUI 编辑器需要 wait 参数或可等待的命令，确保 Qwen Code 会阻塞直到用户保存并关闭编辑器，例如 code --wait 或 zed --wait。
What would you like to be added?
The prompt input's external editor action (
Ctrl+X/ open input in external editor) should respect the editor selected through/editor/general.preferredEditor.Current behavior:
/editorsetsgeneral.preferredEditor, but the prompt input external editor path only checks$VISUAL,$EDITOR, and then a platform fallback. As a result, users can select an editor in Qwen Code and still seeCtrl+Xopen a different editor.Expected behavior: when opening the prompt input in an external editor, prefer
general.preferredEditorfirst. If it is not set, fall back to$VISUAL, then$EDITOR, then the existing platform fallback.Why is this needed?
This makes
/editorbehave consistently with what users expect from an external editor preference. Without it, the setting appears to work in some places but not in the prompt editor flow, which is confusing and makes the feature feel unreliable.Additional context
A possible implementation direction is to pass the resolved
general.preferredEditorinto the prompt input's external-editor path, or share the existing editor resolution logic used elsewhere. GUI editors need wait flags or wait-capable commands so Qwen Code blocks until the user saves and closes the editor, for examplecode --waitorzed --wait.中文
希望增加什么？
prompt 输入框的外部编辑器操作（
Ctrl+X/ 在外部编辑器中打开输入）应该遵循/editor/general.preferredEditor中选择的编辑器。现状：
/editor会设置general.preferredEditor，但 prompt 输入框的外部编辑器路径只读取$VISUAL、$EDITOR，然后使用平台 fallback。因此用户在 Qwen Code 中选择了编辑器后，Ctrl+X仍可能打开另一个编辑器。期望：打开 prompt 输入内容的外部编辑器时，优先使用
general.preferredEditor。如果未设置，再回退到$VISUAL、$EDITOR，最后使用现有平台 fallback。为什么需要？
这能让
/editor的行为符合用户对“外部编辑器首选项”的预期。否则该设置在部分场景生效、在 prompt 编辑器流程中不生效，会让用户困惑，也让功能显得不一致。其他上下文
一种可能实现方向是把解析后的
general.preferredEditor传入 prompt 输入框的外部编辑器路径，或者复用其他地方已有的编辑器解析逻辑。GUI 编辑器需要 wait 参数或可等待的命令，确保 Qwen Code 会阻塞直到用户保存并关闭编辑器，例如code --wait或zed --wait。