fix: remove -i flag from SSH login shell to prevent remote chat errors#40
fix: remove -i flag from SSH login shell to prevent remote chat errors#40
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b0f6d49234
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pub fn get_session_usage_stats(session_id: String) -> Result<ZeroclawUsageStatsResponse, String> { | ||
| let stats = crate::runtime::zeroclaw::process::get_session_usage(&session_id); |
There was a problem hiding this comment.
get_session_usage_stats now serves data from the new per-session map, but there is no call site that writes to that map during request execution (the only writer is record_session_usage, which is introduced but never invoked), so this endpoint always returns zeroed stats. In practice the new TokenBadge path never renders because totalTokens stays 0, making the session usage/cost feature non-functional.
Useful? React with 👍 / 👎.
src/components/ModelSwitcher.tsx
Outdated
| const handleSelect = async (model: string) => { | ||
| try { | ||
| await invoke("set_session_model_override", { sessionId, model }); | ||
| setOverride(model); |
There was a problem hiding this comment.
This UI persists a “session model override”, but the runtime model-selection path still reads only the global preference (load_zeroclaw_model_preference in run_zeroclaw_message) and never reads the new per-session override store, so selecting a model here does not change which model is actually used. That creates a misleading control where users think they switched models for a session but requests continue on the previous model.
Useful? React with 👍 / 👎.
Root cause: wrap_login_shell_eval() used bash -ilc (interactive+login). The -i flag triggers job control setup which fails without a TTY on SSH exec channels, producing 'cannot set terminal process group' errors. Changes: - shell.rs: use -lc (login only) instead of -ilc - agent.rs: try extracting JSON from stdout before checking exit code, making remote chat resilient to stderr-only warnings - use-api.ts: add missing method name to chatViaOpenclaw dispatch so error messages show actual operation instead of 'unknown'
dev01lay2
force-pushed
the
fix/ssh-interactive-shell-error
branch
from
42dc8be to
c763a72
Compare
Keith-CY
left a comment
Keith-CY
left a comment
There was a problem hiding this comment.
LGTM. Fix is scoped and consistent with the reported SSH non-TTY failure: uses login shell without -i for bash/zsh, preserves JSON parsing on stderr-warning non-zero exits, and includes the missing API operation name for error context. I didn’t identify blocking issues.
2 participants
Problem
Remote chat via SSH fails with:
This causes
操作 'unknown' 在 'remote_ssh' 环境执行失败in the Chat panel.Root Cause
wrap_login_shell_eval()inclawpal-core/src/shell.rsusedbash -ilc(interactive + login). The-iflag triggers job control setup (set -o monitor) which requires a TTY. SSH exec channels don't have a TTY, so bash emits warnings to stderr and exits with code 1 on strict configurations.Fix
shell.rs: Changed-ilc→-lc(login only). This still loads.bash_profile/.zprofilefor PATH setup without requiring a terminal.agent.rs:remote_chat_via_openclawnow tries to extract JSON from stdout before checking exit code. This makes it resilient to cases where stderr warnings cause non-zero exit but the command actually succeeded.use-api.ts: Added missing"chatViaOpenclaw"method name todispatch()call so error messages show the actual operation instead of'unknown'.