Make dev app identity opt-in

[shanselman]

Summary

• keep release app identity as the default for every build configuration
• add explicit dev identity opt-ins via build.ps1 -DevBuild and run-app-local.ps1 -Dev
• write and validate app-identity.txt for normal build output so -NoBuild cannot launch the wrong identity
• document the side-by-side dev launch path

Validation

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 2697 passed / 31 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 1579 passed
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore --filter FullyQualifiedName~InstallerIssAssertionTests — 12 passed
• ./build.ps1 -Project WinUI -DevBuild

Real behavior proof

• Default build/run path writes and accepts app-identity.txt=release; ./run-app-local.ps1 -NoBuild -DryRun reports Identity: Release (default).
• Dev build/run path writes and accepts app-identity.txt=dev; ./run-app-local.ps1 -NoBuild -Dev -DryRun reports Identity: Dev (opt-in).
• Mismatch proof: ./run-app-local.ps1 -NoBuild -Dev -DryRun rejects release output, and ./run-app-local.ps1 -NoBuild -DryRun rejects dev output with Build output identity ... does not match requested ....
• Rubber-duck/code-review pass found no remaining blocking findings after the WinApp dev hint was fixed.

[clawsweeper]

Codex review: found issues before merge. Reviewed July 6, 2026, 7:02 PM ET / 23:02 UTC.

Summary
The PR makes local dev app identity opt-in by removing Debug's implicit DevBuild, adding build.ps1 -DevBuild and run-app-local.ps1 -Dev, writing app-identity.txt, and documenting/testing the new flow.

Reproducibility: yes. for the PR finding via source inspection: on the PR head, the advertised dev WinApp command still passes the tracked release Package.appxmanifest to winapp run. I did not run WinAppCLI on Windows in this read-only review.

Review metrics: 2 noteworthy metrics.

• Changed surface: 5 files, +67/-10. The PR touches build/run scripts, the WinUI project, README docs, and source-text tests for a default identity change.
• Identity defaults: Debug dev default removed; 2 opt-in switches added. This changes existing local build behavior rather than only adding a new optional path.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Fix or remove the advertised -Dev -UseWinApp path so it cannot use the release manifest for dev activation.
• Get maintainer confirmation that release identity should be the default for all build configurations.

Risk before merge

• [P1] build.ps1 -DevBuild advertises run-app-local.ps1 -NoBuild -UseWinApp -Dev, but that path still gives WinAppCLI the tracked release manifest, so dev WinApp activation can run with mismatched identity/protocol.
• [P1] Removing Debug's automatic dev identity changes existing local build behavior from isolated dev state to release identity/state unless developers opt into the new switches.

Maintainer options:

1. Fix dev WinApp activation before merge (recommended)
   Update run-app-local.ps1 -Dev -UseWinApp to use a generated dev manifest, or stop advertising that command until it is supported.
2. Accept the default flip explicitly
   A maintainer can accept that Debug/local launches now use release identity unless developers opt into the dev switches.
3. Pause if dev-by-default was intentional
   If Debug dev identity remains the desired contributor default, pause or close this PR rather than merging the default reversal.

Next step before merge

• [P2] Maintainer review is needed because the patch combines a mechanical WinApp manifest blocker with a product decision about changing Debug's default app identity.

Maintainer decision needed

• Question: Should local Debug builds default to the release app identity, with side-by-side dev identity available only through -DevBuild or -Dev after WinApp support is repaired?
• Rationale: Current main intentionally made Debug builds dev-identity by default for side-by-side safety, and this PR deliberately reverses that default while adding new launch/build switches.
• Likely owner: karkarl — The default being changed was introduced in karkarl's side-by-side identity feature work.
• Options:
  • Accept opt-in dev identity after WinApp fix (recommended): Merge the default flip once -Dev -UseWinApp uses a matching dev manifest or the unsupported hint is removed.
  • Keep Debug dev-by-default: Preserve current side-by-side Debug behavior and narrow this PR to marker validation or documentation only.
  • Require workflow proof first: Hold the PR until docs and proof cover existing developer workflows that depend on Debug using dev identity by default.

Security
Cleared: The diff changes local build/run scripts, MSBuild identity properties, docs, and tests; I found no concrete new secret, permission, dependency, CI, or supply-chain exposure.

Review findings

• [P2] Use a dev manifest for WinApp dev launches — build.ps1:466

Review details

Best possible solution:

Land the opt-in dev identity flow only after dev WinApp activation uses a matching dev manifest or no longer advertises that mode, with maintainer-confirmed default identity semantics.

Do we have a high-confidence way to reproduce the issue?

Yes for the PR finding via source inspection: on the PR head, the advertised dev WinApp command still passes the tracked release Package.appxmanifest to winapp run. I did not run WinAppCLI on Windows in this read-only review.

Is this the best way to solve the issue?

No, not yet. Marker validation covers the direct local launch path, but dev WinApp activation needs a matching manifest or the unsupported path should be hidden before this is the narrow maintainable solution.

Full review comments:

• [P2] Use a dev manifest for WinApp dev launches — build.ps1:466
  This is the same blocker from the prior ClawSweeper cycle and it remains on the current head. build.ps1 -DevBuild now advertises run-app-local.ps1 -NoBuild -UseWinApp -Dev, but run-app-local.ps1 still always passes the tracked Package.appxmanifest to WinAppCLI. That manifest stays release identity/protocol while the executable is compiled as DEV_BUILD, so the advertised side-by-side WinApp validation path can launch with mismatched identity. Generate/select a dev manifest for -Dev -UseWinApp, or stop advertising that combination.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.82

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 856c620d2cca.

Label changes

Label justifications:

• P2: This is a bounded dev-tooling and local launch compatibility change with a concrete review blocker, not a production crash or urgent user workflow failure.
• merge-risk: 🚨 compatibility: Merging changes existing Debug/local identity defaults and can make developer workflows use release identity/state unless they opt into the new dev switches.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body lists validation commands and live-output style dry-run results for release, dev, and mismatch paths; that is sufficient for the direct-launch proof gate, though the WinApp path still needs the code fix above.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body lists validation commands and live-output style dry-run results for release, dev, and mismatch paths; that is sufficient for the direct-launch proof gate, though the WinApp path still needs the code fix above.

Evidence reviewed

What I checked:

• Repository policy read: Read the full target AGENTS.md; its validation and proof guidance applies because this PR touches tray local launch/build identity tooling, but this cleanup review is read-only so I did not run artifact-producing validation commands. (AGENTS.md:1, 856c620d2cca)
• PR changes default identity and adds opt-in switches: The PR removes Debug's implicit dev identity default and adds explicit build/run opt-ins plus build-output identity marker validation. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:17, e21dc3d57ec0)
• Current main default being changed: Current main makes Debug builds set DevBuild=true by default, so this PR deliberately reverses an existing local-development default. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:17, 856c620d2cca)
• WinApp dev path still uses source manifest: On the PR head, run-app-local.ps1 still sets $manifestPath to the tracked Package.appxmanifest and passes it to winapp run, even when -Dev selected a dev build output. (run-app-local.ps1:157, e21dc3d57ec0)
• Dev manifest generation remains MSIX-scoped: The project only generates the dev package manifest inside the MSIX manifest target, so a normal build.ps1 -DevBuild path does not automatically provide WinAppCLI with a dev manifest. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:184, e21dc3d57ec0)
• Feature history provenance: git blame and commit metadata tie the side-by-side identity constants, Debug dev default, and installer assertions to the merged side-by-side identity work in dae64b6c. (src/OpenClaw.Tray.WinUI/AppIdentity.cs:1, dae64b6c49e9)

Likely related people:

• karkarl: Co-authored the merged side-by-side dev/release identity work that introduced AppIdentity, the Debug dev default, dev manifest generation, and related installer assertions. (role: feature owner; confidence: high; commits: dae64b6c49e9; files: src/OpenClaw.Tray.WinUI/AppIdentity.cs, src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj, tests/OpenClaw.Tray.Tests/InstallerIssAssertionTests.cs)
• shanselman: Introduced the local run helper surface on main and authored this PR's proposed build/run identity switch changes. (role: recent area contributor; confidence: high; commits: 4166e0fd63f8, e21dc3d57ec0; files: run-app-local.ps1, build.ps1, README.md)
• steipete: Recently maintained the local Inno build identity-validation path adjacent to this PR's marker validation changes. (role: recent adjacent contributor; confidence: medium; commits: 38fd2cf15e71; files: scripts/build-inno-local.ps1, tests/OpenClaw.Tray.Tests/InstallerIssAssertionTests.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (1 earlier review cycle)

• reviewed 2026-07-06T22:49:16.120Z sha e21dc3d :: found issues before merge. :: [P2] Use a dev manifest for WinApp dev launches