Skip to content

feat(runtime): restore mobile control page#1968

Open
axobase001 wants to merge 3 commits into
Hmbown:mainfrom
axobase001:feat/mobile-remote-control
Open

feat(runtime): restore mobile control page#1968
axobase001 wants to merge 3 commits into
Hmbown:mainfrom
axobase001:feat/mobile-remote-control

Conversation

@axobase001
Copy link
Copy Markdown
Contributor

Rebased replacement for #852 after the v0.8.41 CodeWhale rebrand.

What changed:

  • adds codewhale serve --mobile as a thin mobile/LAN entry point over the existing runtime HTTP/SSE API
  • serves a built-in /mobile control page from a separate runtime_mobile.html file via include_str!
  • uses the current /v1/approvals/{approval_id} bridge instead of restoring the old per-turn approval routes
  • keeps the already-merged runtime token guard intact rather than reintroducing the old feat(runtime): add mobile remote control #852 auth implementation
  • updates runtime API docs plus README command listings

Validation:

  • cargo fmt --all
  • git diff --check
  • cargo check -p codewhale-tui --locked
  • cargo test -p codewhale-tui --bin codewhale-tui --locked runtime_api::tests::
  • local smoke: codewhale-tui serve --mobile --port 7879 --insecure, GET /mobile returned HTTP 200 with title CodeWhale Mobile

Note: cargo test -p codewhale-tui --locked runtime_api::tests:: also passed the runtime API module tests, but the full cargo invocation then tried to launch the filtered skill_install integration binary on Windows and hit OS error 740 (requires elevation). The bin-scoped command above avoids that unrelated Windows integration-test launcher issue.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a built-in mobile control page for the codewhale serve command, accessible via a new --mobile flag. This feature enables thread management and tool approval resolution from mobile devices on the same LAN. Key changes include a new single-page HTML/JS interface, CLI updates to handle network binding, and expanded SSE event support. Reviewers recommended URL-encoding the runtime token in the displayed URLs and refining the LAN IP detection logic to avoid dependencies on hardcoded external DNS servers like 8.8.8.8.

token
.filter(|token| !token.trim().is_empty())
.map(|token| format!("?token={token}"))
.unwrap_or_default()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The token is appended to the URL without percent-encoding. If a manually configured token contains characters like &, #, or +, it will corrupt the query string or lead to authentication failures, as the server-side token_from_query (and the mobile page's own JS) expects correctly formatted parameters. Consider URL-encoding the token here for robustness.

Comment thread crates/tui/src/runtime_api.rs Outdated

fn detect_lan_ip() -> Option<String> {
let socket = UdpSocket::bind("0.0.0.0:0").ok()?;
socket.connect("8.8.8.8:80").ok()?;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Hardcoding 8.8.8.8 for LAN IP detection might not work for users in regions where Google services are blocked (e.g., China), which is a key demographic for this project. Consider using a more neutral target or a non-routable IP like 10.255.255.255:1 to determine the default interface's local address without sending actual packets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant