Enter key does not submit input in remote TUI mode
Summary
In remote TUI mode (TUI client connecting to jcode serve), pressing Enter in the input box does nothing. The text is consumed (input field clears visually in some cases) but no message is sent to the server, and no error/status notice is shown.
Reproduction
- Start server:
jcode --provider auto serve
- Start TUI client:
~/.jcode/builds/current/jcode
- Type any text (e.g.
hello world, test prompt, etc.) — even simple non-slash input
- Press Enter
- Expected: prompt is sent to the model, response streams back
- Actual: input field appears empty (or unchanged), nothing happens, no log entries on the server
Root cause
File: crates/jcode-tui/src/tui/app/commands.rs:3328
Function handle_disabled_mission_command was stubbed down to a single true:
pub fn handle_disabled_mission_command(_app: &mut crate::tui::app::App, _cmd: &str) -> bool {
true
}
This function is called in the Enter dispatch chain:
crates/jcode-tui/src/tui/app/remote/key_handling.rs:1728 — if app_mod::commands::handle_disabled_mission_command(app, trimmed) { return Ok(()); }
crates/jcode-tui/src/tui/app/remote.rs:1396 — same pattern
Because the function unconditionally returns true, every Enter press is consumed and the submit handler is never reached, regardless of the actual input content.
How it was introduced
Commit bb0f535e fix(jcode-tui): down to 6 E0061 arg count errors only on the feature-planning branch stubbed this function to satisfy the compiler after splitting the original handle_mission_command (in commit 39410e34 feat: add /goal command) into two functions. The original (correct) logic from upstream master (commit 793759e7 Disable mission and goal slash commands) was lost.
Why master is unaffected
master carries the upstream version of the function (introduced by 793759e7 in the upstream 1jehuang/jcode repo), which returns false for any input that is not /mission or /goal:
pub(super) fn handle_disabled_mission_command(app: &mut App, trimmed: &str) -> bool {
if slash_command_rest(trimmed, "/mission").is_none()
&& slash_command_rest(trimmed, "/goal").is_none()
{
return false;
}
app.push_display_message(DisplayMessage::system(
"The /mission and /goal commands are disabled in this build.".to_string(),
));
true
}
Fix
Restore the function body to match the upstream master version shown above. The two call sites in key_handling.rs:1728 and remote.rs:1396 are kept as-is.
Scope of impact
- Affects remote TUI mode only (TUI client →
jcode serve). The local TUI event path in crates/jcode-tui/src/tui/app/input.rs does not call this function.
- Affects every Enter press, including plain text, slash commands, and
/mission / /goal.
- Server logs show no
API stream attempt or submit events from the affected client session.
Debug trace (before fix)
Sample log from a TUI client with debug instrumentation injected at the Enter dispatch entry and before every return Ok(()) in the Enter chain:
[DEBUG-ENTER] prepared.raw_input=".ádas." prepared.expanded=".ádas." trimmed=".ádas." trimmed.is_empty=false trimmed_starts_slash=false inline_state=false route_next_new=false queue_mode=false is_processing=false
[DEBUG-ENTER] checking /help/? branches. trimmed=".ádas." starts_help=false
[DEBUG-ENTER-RET] line=1729 <-- handle_disabled_mission_command always returns true here
The line=1729 corresponds to the return Ok(()); directly inside if app_mod::commands::handle_disabled_mission_command(...) { return Ok(()); } in key_handling.rs.
Enter key does not submit input in remote TUI mode
Summary
In remote TUI mode (TUI client connecting to
jcode serve), pressing Enter in the input box does nothing. The text is consumed (input field clears visually in some cases) but no message is sent to the server, and no error/status notice is shown.Reproduction
jcode --provider auto serve~/.jcode/builds/current/jcodehello world,test prompt, etc.) — even simple non-slash inputRoot cause
File:
crates/jcode-tui/src/tui/app/commands.rs:3328Function
handle_disabled_mission_commandwas stubbed down to a singletrue:This function is called in the Enter dispatch chain:
crates/jcode-tui/src/tui/app/remote/key_handling.rs:1728—if app_mod::commands::handle_disabled_mission_command(app, trimmed) { return Ok(()); }crates/jcode-tui/src/tui/app/remote.rs:1396— same patternBecause the function unconditionally returns
true, every Enter press is consumed and the submit handler is never reached, regardless of the actual input content.How it was introduced
Commit
bb0f535e fix(jcode-tui): down to 6 E0061 arg count errors onlyon thefeature-planningbranch stubbed this function to satisfy the compiler after splitting the originalhandle_mission_command(in commit39410e34 feat: add /goal command) into two functions. The original (correct) logic from upstreammaster(commit793759e7 Disable mission and goal slash commands) was lost.Why master is unaffected
mastercarries the upstream version of the function (introduced by793759e7in the upstream1jehuang/jcoderepo), which returnsfalsefor any input that is not/missionor/goal:Fix
Restore the function body to match the upstream master version shown above. The two call sites in
key_handling.rs:1728andremote.rs:1396are kept as-is.Scope of impact
jcode serve). The local TUI event path incrates/jcode-tui/src/tui/app/input.rsdoes not call this function./mission//goal.API stream attemptorsubmitevents from the affected client session.Debug trace (before fix)
Sample log from a TUI client with debug instrumentation injected at the Enter dispatch entry and before every
return Ok(())in the Enter chain:The
line=1729corresponds to thereturn Ok(());directly insideif app_mod::commands::handle_disabled_mission_command(...) { return Ok(()); }inkey_handling.rs.