Skip to content

fix(photon): hide Windows sidecar console window - #65083

Closed
ianarsenault-tn wants to merge 1 commit into
NousResearch:mainfrom
ianarsenault-tn:agent/fix-photon-windows-sidecar-window
Closed

fix(photon): hide Windows sidecar console window#65083
ianarsenault-tn wants to merge 1 commit into
NousResearch:mainfrom
ianarsenault-tn:agent/fix-photon-windows-sidecar-window

Conversation

@ianarsenault-tn

Copy link
Copy Markdown

Summary

  • hide the long-lived Photon/iMessage Node sidecar console on Windows
  • keep POSIX behavior unchanged with start_new_session=True
  • add regression coverage for the Windows sidecar spawn kwargs

Why

When Photon messages are enabled from Hermes Desktop on Windows, the sidecar is expected to keep running in the background. Today it can also create a visible blank Windows Terminal/conhost window for node.exe, which is distracting and looks like an app error. start_new_session does not detach or hide console windows on Windows, so the sidecar needs explicit Windows process flags and hidden STARTUPINFO.

Validation

  • python -m py_compile plugins/platforms/photon/adapter.py
  • git diff --check
  • uv run --with pytest --with pytest-asyncio python -m pytest tests/plugins/platforms/photon/test_sidecar_lifecycle.py -k "start_sidecar"

Note: the full test_sidecar_lifecycle.py file currently has unrelated Windows failures in the orphan-reaping tests, which expect signal behavior that is not exercised by this patch. The two sidecar startup tests pass.

@ianarsenault-tn
ianarsenault-tn marked this pull request as ready for review July 15, 2026 20:39
@ianarsenault-tn

Copy link
Copy Markdown
Author

This is ready for review. I confirmed the issue on Windows Desktop with Photon/iMessage enabled: the long-lived Photon sidecar keeps a visible blank Windows Terminal/conhost window open for node.exe. The sidecar process itself is expected, but the visible console is not. This patch keeps POSIX behavior unchanged and adds Windows creation flags plus hidden STARTUPINFO for the sidecar spawn. Validation: py_compile on the Photon adapter, git diff --check, and the targeted sidecar startup tests passed with 2 passed / 4 deselected.

@alt-glitch alt-glitch added type/bug Something isn't working P3 Low — cosmetic, nice to have comp/plugins Plugin system and bundled plugins platform/windows Native Windows-specific behavior or breakage sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows duplicate This issue or pull request already exists labels Jul 15, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

This was generated by AI during triage.

Duplicate of #55554: both add Windows hidden-process flags at Photon _start_sidecar; #55554 is the earlier, broader implementation.

@ianarsenault-tn

Copy link
Copy Markdown
Author

Thanks for the pointer. I agree #55554 is the earlier PR for the same Photon sidecar window issue. The main differences here are: (1) this PR includes regression coverage for the Windows sidecar spawn kwargs, which the sweeper review on #55554 requested, and (2) it adds hidden STARTUPINFO in addition to process creation flags. On my Windows Desktop setup with Photon enabled, the sidecar node.exe was still getting a visible Windows Terminal/conhost window, so the extra STARTUPINFO coverage is intended to keep the sidecar background-only. Happy to close this in favor of #55554 if maintainers prefer that route, or this can serve as the tested variant/reference for the missing coverage.

@teknium1 teknium1 left a comment

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.

Thanks for adding focused Windows regression coverage. The current-main premise is valid: Photon starts the patch Node process at plugins/platforms/photon/adapter.py:948-958 and the persistent sidecar at plugins/platforms/photon/adapter.py:969-976 without no-window flags.

Problems

  • The new sidecar kwargs combine DETACHED_PROCESS with stdin=PIPE / stdout=PIPE (plugins/platforms/photon/adapter.py:1002 in this PR). The repository's compatibility contract says DETACHED_PROCESS severs stdio and breaks stdout capture (hermes_cli/_subprocess_compat.py:194-197), conflicting with the supervisor and EOF shutdown design.
  • The patch-script Node invocation remains unprotected at plugins/platforms/photon/adapter.py:948-958. Related PR #55554 applies windows_hide_flags() to both calls.

Suggested changes

  • Use windows_hide_flags() / CREATE_NO_WINDOW for both spawn sites, preserving the existing pipe lifecycle.
  • Adjust the test to cover both subprocess calls and assert the hide flag, not detach flags.

Automated hermes-sweeper review.

stderr=subprocess.STDOUT,
env=env,
start_new_session=(sys.platform != "win32"),
**_sidecar_popen_kwargs(),

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.

DETACHED_PROCESS conflicts with this sidecar's stdin=PIPE/stdout=PIPE lifecycle. hermes_cli/_subprocess_compat.py:194-197 documents that it severs stdio and breaks stdout capture; use the established windows_hide_flags()/CREATE_NO_WINDOW value instead.

@teknium1 teknium1 added sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-contained Sweeper blast radius: contained — one narrow path / opt-in / few users labels Jul 16, 2026
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the fix — this was a real bug, confirmed on main. It was independently fixed by five contributors; we merged the earliest submission (#54565 by @lEWFkRAD, Jun 29) via PR #65441, which uses the repo's shared windows_hide_flags() helper from hermes_cli/_subprocess_compat.py and covers the npm self-heal spawn sites as well. Your PR is credited in the merged PR body. Closing as a duplicate — thanks again!

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

Labels

comp/plugins Plugin system and bundled plugins duplicate This issue or pull request already exists P3 Low — cosmetic, nice to have platform/windows Native Windows-specific behavior or breakage sweeper:blast-contained Sweeper blast radius: contained — one narrow path / opt-in / few users sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants