* fix(daemon): skip machine-scope fallback on permission-denied bus errors; fall back to --user when sudo machine scope fails
When systemctl --user fails with "Failed to connect to bus: Permission
denied", the machine-scope fallback is now skipped. A Permission denied
error means the bus socket exists but the process cannot connect to it,
so --machine user@ would hit the same wall.
Additionally, the sudo path in execSystemctlUser now tries machine scope
first but falls through to a direct --user attempt if it fails, instead
of returning the error immediately.
Fixes#61959
* fix(daemon): guard against double machine-scope call when sudo path already tried it
When SUDO_USER is set and machine scope fails with a non-permission-denied
bus error, execution falls through to the direct --user attempt. If that
also fails with a bus-unavailable message, shouldFallbackToMachineUserScope
returns true and machine scope is tried a second time -- a redundant exec
that was never reachable before this PR opened the fallthrough path.
Add machineScopeAlreadyTried flag and include it in the bottom-fallback
guard condition so the second call is skipped when machine scope was
already attempted in the sudo branch.
Add regression test asserting exactly 2 execFile calls in this scenario.
* fix: keep sudo systemctl scoped
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* Auth: fix native model profile selection
Fix native `/model ...@profile` targeting so profile selections persist onto the intended session, and preserve explicit session auth-profile overrides even when stored auth order prefers another profile. Update the reply/session regressions to use placeholder example.test profile ids.
Regeneration-Prompt: |
Native `/model ...@profile` commands in chat were acknowledging the requested auth profile but later runs still used another account. Fix the target-session handling so native slash commands mutate the real chat session rather than a slash-session surrogate, and keep explicit session auth-profile overrides from being cleared just because stored provider order prefers another profile. Update the tests to cover the target-session path and the override-preservation behavior, and use placeholder profile ids instead of real email addresses in test fixtures.
* Auth: honor explicit user-locked profiles in runner
Allow an explicit user-selected auth profile to run even when per-agent auth-state order excludes it. Keep auth-state order for automatic selection and failover, and add an embedded runner regression that seeds stored order with one profile while verifying a different user-locked profile still executes.
Regeneration-Prompt: |
The remaining bug after fixing native `/model ...@profile` persistence was in the embedded runner itself. A user could explicitly select a valid auth profile for a provider, but the run still failed if per-agent auth-state order did not include that profile. Preserve the intended semantics by validating user-locked profiles directly for provider match and credential eligibility, then using them without requiring membership in resolved auto-order. Add a regression in the embedded auth-profile rotation suite where stored order only includes one OpenAI profile but a different user-locked profile is chosen and must still be used.
* Changelog: note explicit auth profile selection fix
Add the required Unreleased changelog line for the explicit auth-profile selection and runner honor fix in this PR.
Regeneration-Prompt: |
The PR needed a mandatory CHANGELOG.md entry under Unreleased/Fixes. Add a concise user-facing line describing that native `/model ...@profile` selections now persist on the target session and explicit user-locked OpenAI Codex auth profiles are honored even when per-agent auth order excludes them, and include the PR number plus thanks attribution for the PR author.