Autostart turned on during setup opens the Companion window at logon

Open
  • Is something wrong?
#1,957 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

@roboclaw-bot is already working on this.

Since Nov 1, 2026.

  • #1963 by @roboclaw-bot — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
20/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
csharp
Domain
desktop

Research direction

Start with the two writers in AutoStartManager (ApplySetupPreferenceAsync and SetUnpackagedAutoStart) and the matcher WindowsStartupTaskRegistration.MatchesExpectedTask, which SetupStartupPolicy.ApplyUnpackaged relies on. Done means the setup Run key value includes --background, the strict check accepts the app's own task, and ActivationRouterTests still passes. Pull request #1963 already implements this, so review or test it rather than starting a new patch.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P2

Summary

When setup turns on Start with Windows in a session without elevation, the registration it falls back to has no --background. Companion then opens its window at every logon instead of starting quietly. A second defect in the same path makes setup report that startup registration could not be confirmed, even when the app's own task is in place.

Cause

Run key without the argument. A logon scheduled task needs elevation here, so schtasks /Create is refused and setup falls back to the Run key. The two writers in AutoStartManager disagree:

// ApplySetupPreferenceAsync, the setup path
key.SetValue(AppName, $"\"{exe}\"");
// SetUnpackagedAutoStart, the Settings path
key.SetValue(AppName, $"\"{exePath}\" --background");

docs/CONNECTION_ARCHITECTURE.md says new autostart registrations pass --background to remain quiet, and ActivationRouterTests pins that an unpackaged launch with no arguments opens a window. installer.iss already migrates this exact argument-free value to --background, but only during an upgrade, and setup can write it again afterwards.

Strict check that rejects the app's own task. WindowsStartupTaskRegistration.MatchesExpectedTask requires empty arguments, while CreateRegisterProcessStartInfo always registers --background. InspectStrict therefore returns Different for a task the app created. It matters when schtasks times out or returns an unclassified error after creating the task: SetupStartupPolicy.ApplyUnpackaged throws "Windows startup registration could not be confirmed". The existing test fixture uses empty arguments, so it did not catch this.

Evidence

Windows 11 x64 build 26200, main a4dd026, standard session without elevation:

schtasks /Create /SC ONLOGON /HRESULT exit: 0x80070005

Tests against the baseline matcher, using a task description with the arguments the app really registers:

Failed OnlyExactEnabledStartupTaskCountsAsCompletedRegistration(changed: "expected", matches: True)
Failed OnlyExactEnabledStartupTaskCountsAsCompletedRegistration(changed: "no-arguments", matches: False)

Fix I have ready

One shared CreateBackgroundLaunchCommand for the scheduled task and both Run key writers, and MatchesExpectedTask now requires --background.

Not verified

  • I did not complete the setup wizard and log on again, so the window at logon comes from the code and the router test, not from watching it happen.
  • The strict check's failure path was tested through the matcher, because a logon task cannot be created on this machine without elevation. The new round-trip test exits early when Windows refuses the task, as it does here, so it only proves something on an elevated host.

I found no existing issue or PR for this. I will open a PR.

Dominant language
C#
Stars
2.2k
Forks
336
Avg merge
3d 22h
Merged PRs (30d)
156

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.