claude-code - 💡(How to fix) Fix [BUG] remoteControlAtStartup: true does not trigger the "Remote Control active" footer indicator (data populated, UI not rendered) [1 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When Remote Control is auto-enabled at startup via "remoteControlAtStartup": true in settings.json, the green "Remote Control active" indicator next to the statusLine footer is not displayed.

Remote control itself functions normally — the session is reachable at https://claude.ai/code/session_… printed during startup, and external clients can connect. The session data file (~/.claude/sessions/{PID}.json) has its bridgeSessionId field populated correctly. Only the footer UI confirmation is missing, which makes it ambiguous from the CLI whether remote control is actually active.

Manually invoking /remote-control from inside the session does produce the indicator as expected.

What Should Happen?

The green "Remote Control active" text should appear next to the statusLine footer whenever remote control is active — regardless of whether activation came from remoteControlAtStartup: true or from the user invoking /remote-control. Both paths should produce identical UI feedback.

Error Messages/Logs

(none — this is a silent UI rendering miss, not a runtime error)

Steps to Reproduce

1. Add the following to ~/.claude/settings.json:

   "remoteControlAtStartup": true

2. Quit Claude Code completely.

3. Start a new session: claude (or claude --resume).

4. Look at the bottom statusLine area in the terminal.

Expected: green "Remote Control active" text on the right. Actual: no indicator, even though the bridge session is active.

To confirm the bridge is active despite the missing UI:

cat ~/.claude/sessions/*.json | jq '.bridgeSessionId'
# Returns "session_..." (non-null), confirming remote control is on.

Now invoke /remote-control manually from inside the same session — the indicator appears. The data was already correct; only the UI trigger was missing on the auto-enable path.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.128

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Diagnostic Findings

The data layer is correct in both paths — the difference is purely in UI rendering:

This strongly suggests the footer rendering is hooked only to the user-command path (/remote-control), and the auto-enable path activates the bridge but skips the UI trigger.

Additionally, the JSON input passed to custom statusLine commands does not include any remote-control field in either case, so users who want to surface this state in a custom statusLine cannot do so via documented input — only by reading ~/.claude/sessions/{PID}.json directly.

Workaround (for affected users)

A custom statusLine command script can detect the state by checking the bridgeSessionId in the matching session file:

session_id=$(echo "${input}" | jq -r '.session_id // ""')
for sf in "${HOME}"/.claude/sessions/*.json; do
  [ -f "${sf}" ] || continue
  if grep -q "\"sessionId\":\"${session_id}\"" "${sf}"; then
    bridge=$(jq -r '.bridgeSessionId // ""' "${sf}")
    if [ -n "${bridge}" ] && [ "${bridge}" != "null" ]; then
      echo "● RC active"
    fi
    break
  fi
done

Suggested Fix

Trigger the same footer-rendering path used by /remote-control after the auto-enable activation completes, so both paths produce identical UI feedback.

As a separate (and arguably more valuable) improvement, exposing remote_control / bridge_session_id in the statusLine JSON input would let users build their own indicators without reading internal session files.