Fix effort persistence display across sessions

[jatmn]

This PR fixes effort display and persistence mismatches across the /effort
picker, the startup banner, and in-app effort labels.

Previously, /effort medium could appear active in one part of the UI while a
new session's startup banner still showed a provider alias/default effort such
as high. The issue was caused by effort display being split across several
paths with slightly different precedence rules.

This PR makes those paths consistently respect:

1. CLAUDE_CODE_EFFORT_LEVEL
2. saved global /effort
3. provider alias reasoning default, when present
4. model/default fallback

What Changed

• Fixed /effort picker persistence:

  • picker selections now route through the same persistence helpers as direct
    /effort commands;
  • selecting Auto from the picker now clears the persisted global
    effortLevel, matching /effort auto;
  • EffortPicker no longer mutates app state before persistence succeeds.

• Fixed startup banner effort display:

  • saved /effort and CLAUDE_CODE_EFFORT_LEVEL now take precedence over
    provider alias defaults;
  • provider alias defaults are still preserved when no saved or env override
    exists, so aliases like gpt-5.4 continue to display their configured
    default effort accurately.

• Unified in-app effort display:

  • getEffortSuffix() now uses the same displayed/effective effort level as
    the bottom-right effort indicator;
  • unsupported models still suppress effort suffixes.

• Cleaned up effort command wiring:

  • removed stale OpenAI-effort picker wiring left after centralizing picker
    state updates through the command result path.

• Updated effort utility typing/imports:

  • imported ant-model helpers used by effort logic;
  • widened toPersistableEffort() input typing so OpenAI-style xhigh
    normalization is accepted.

• Updated docs:

  • documented CLAUDE_CODE_EFFORT_LEVEL in .env.example;
  • documented /effort persistence vs env override precedence in
    docs/advanced-setup.md.

Tests

Added coverage for:

• startup banner uses provider alias default when no saved/env effort exists;
• startup banner uses saved /effort over provider alias default;
• startup banner uses CLAUDE_CODE_EFFORT_LEVEL over saved /effort;
• effort suffix uses the effective displayed effort for supported models;
• unsupported models do not show effort suffixes.

Validation

Ran focused tests:

bun test src/components/StartupScreen.test.ts src/utils/effort.codex.test.ts

Result:

48 pass
0 fail
72 expect() calls

Also ran:

git diff --check origin/main...HEAD

Result: no whitespace errors.

Notes

The full repo bun run typecheck still reports broad unrelated baseline issues
in generated/missing-module and non-effort areas.

[Vasanthdev2004]

Targeted review of current head 93a831ef, focused on the CI auth change and the effort/startup behavior changed in this PR.

Verdict: Needs changes

Blocking issues:

1. Focused tests fail locally:
   • detectProvider — startup effort display no longer appends the effective effort for gpt-5.4.
   • the Anthropic modelOverride alias test receives gpt-5.5 instead of resolving opus, which suggests provider/default state changed unexpectedly in this path.
2. The workflow change scopes GITHUB_TOKEN to bun install --frozen-lockfile. That exposes the repo token to every dependency install/postinstall script. For a PR workflow, that is too broad. If ripgrep install needs authenticated GitHub access, please scope the token only to the specific download/install step or use a safer mechanism that does not place the token in the full dependency install environment.

Validation:

• bun test ./src/utils/effort.codex.test.ts ./src/components/StartupScreen.test.ts
• Result: effort.codex passes, StartupScreen.test.ts has 4 failures.

Happy to re-review once the tests pass and the token exposure is narrowed.

[techbrewboss]

Reviewed current head 5141b37. The effort precedence changes now look consistent across the picker, startup banner, and suffix display, and the CI token workaround is narrowed to the ripgrep fallback instead of the full install environment.

Validated locally:

bun test src/components/StartupScreen.test.ts src/utils/effort.codex.test.ts

Result: 48 pass, 0 fail. I also checked the current GitHub PR checks; both smoke-and-tests and web are passing.

No blocking findings from me.

[Vasanthdev2004]

Targeted re-review of current head 5141b37, focused on the effort-display tests and the CI token-scoping concern from my earlier review.

Verdict: Approve-ready

What I checked:

• Startup banner effort precedence now matches the intended order: env override, saved /effort, provider alias default, model/default fallback.
• The prior focused StartupScreen.test.ts failures are fixed.
• The CI auth workaround is no longer scoped across the full dependency install path.
• Ran bun test ./src/components/StartupScreen.test.ts ./src/utils/effort.codex.test.ts: 48/48 passing.

I do not see a remaining blocker on current head.

[jatmn]

@kevincodex1

[Vasanthdev2004]

Blockers

None.

Non-Blocking

None.

Looks Good

• Fixes effort persistence display across sessions
• 221 additions, 111 deletions — focused fix
• Already has maintainer approvals

---

Verdict: Approve — clean effort persistence fix.

[Vasanthdev2004]

Clean effort persistence fix.

[gnanam1990]

The effort-precedence unification itself looks solid — picker/banner/suffix now share one chain, the "don't mutate app state before persistence succeeds" change is a genuine bug fix, and the test coverage on current head is good. Removing the stale tengu_effort_command call from the picker wrapper is a nice cleanup too. One thing to address before approve:

This PR also modifies .github/workflows/pr-checks.yml and release.yml. The token scoping was correctly narrowed after earlier feedback so I'm not worried about exposure — but a "fix effort display" PR shouldn't carry CI plumbing for an unrelated ripgrep-install flake. Could you split the workflow changes into their own PR so each can be reviewed on its own merits and this one stays focused?

Minor housekeeping: please drop the Co-Authored-By: OpenClaude (gpt-5.5) trailer on 2cef0c9 before merge, per convention. Happy to approve the effort changes as soon as the CI bits are split out — thanks!

[techbrewboss]

Review summary

Thanks for narrowing the PR back to the effort-display/persistence scope. The runtime direction looks valuable, and I did not find suspicious or malicious behavior in the current eight-file diff. I do see one blocking test-isolation issue that keeps the PR from being merge-ready.

Findings

• src/utils/effort.codex.test.ts:91 - Effort test mocks still leak into StartupScreen.test.ts.
  Impact: the PR's own focused validation command fails when run as stated. importFreshEffortModule() installs fixed provider/support mocks, and because Bun module mocks are process-global, the last codex / unsupported mock bleeds into StartupScreen.test.ts. That makes the startup effort assertions receive gpt-5.4 instead of gpt-5.4 (high|medium|low), and makes the Anthropic opus alias resolve to gpt-5.5.
  Suggested fix: avoid leaving fixed provider mocks installed across files. Reset the provider/providerConfig mocks to an env-driven or actual implementation after each test, or isolate this suite so StartupScreen.test.ts sees the real provider modules. The claimed command should pass reliably:

bun test src/components/StartupScreen.test.ts src/utils/effort.codex.test.ts

Validation

• bun test src/components/StartupScreen.test.ts passes: 39 pass, 0 fail.
• bun test src/components/StartupScreen.test.ts src/utils/effort.codex.test.ts fails: 44 pass, 4 fail.
• Current GitHub checks show smoke-and-tests and web passing, but the local focused validation above reproduces the order-dependent failure.