Skip to content

fix(web): expose Codex Fast and Plan on Create Session#1017

Open
swear01 wants to merge 6 commits into
tiann:mainfrom
swear01:fix/codex-create-fast-personality-plan
Open

fix(web): expose Codex Fast and Plan on Create Session#1017
swear01 wants to merge 6 commits into
tiann:mainfrom
swear01:fix/codex-create-fast-personality-plan

Conversation

@swear01

@swear01 swear01 commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Summary

Personality: still blocked on #1003 / #1009 — upstream chat Settings does not expose Personality yet, so Create deliberately matches current chat Settings (Fast + Plan only). Follow-up after #1009 merges.

Test plan

  • Create Codex session with Collaboration = Plan → new session starts in plan mode (StatusBar / Settings show Plan)
  • Create Codex session with Fast Mode = Fast (when model advertises Fast) → serviceTier is fast
  • Fast Mode selector hidden when catalog does not advertise Fast for selected/default model
  • Non-Codex agents: selectors absent; spawn payload omits the new fields
  • bun run test -- src/commands/codex.test.ts src/runner/buildCliArgs.test.ts (cli)
  • bun run test -- src/components/NewSession/newSessionFormDraft.test.ts (web)

Made with Cursor

Wire serviceTier and collaborationMode through spawn so Create can set
the same Codex options chat Settings already supports (tiann#1015).

Co-authored-by: Cursor <cursoragent@cursor.com>

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  • [Major] collaborationMode is dropped before the runner sees it — the hub now includes collaborationMode in the machine RPC payload, but the CLI machine RPC handler still only destructures and forwards the older fields. A Create Session request with Collaboration = Plan will therefore spawn hapi codex without --collaboration-mode plan, so the new selector has no effect. Evidence: hub/src/sync/rpcGateway.ts:162; receiver context: cli/src/api/apiMachine.ts:262 and cli/src/api/apiMachine.ts:273.
    Suggested fix:
    const { directory, sessionId, resumeSessionId, machineId, approvedNewDirectoryCreation, agent, model, effort, modelReasoningEffort, yolo, permissionMode, serviceTier, collaborationMode, token, sessionType, worktreeName } = params || {}
    
    const result = await spawnSession({
        directory,
        sessionId,
        resumeSessionId,
        machineId,
        approvedNewDirectoryCreation,
        agent,
        model,
        effort,
        modelReasoningEffort,
        yolo,
        permissionMode,
        serviceTier,
        collaborationMode,
        token,
        sessionType,
        worktreeName
    })

Summary

  • Review mode: initial
  • Found one Major issue in the new spawn plumbing: Plan mode is accepted by web/hub but lost at the CLI machine RPC boundary.

Testing

  • Not run (automation; static review only).

HAPI Bot

effort,
permissionMode,
serviceTier,
collaborationMode

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[MAJOR] collaborationMode is added to the machine RPC payload here, but the CLI receiver still drops it: cli/src/api/apiMachine.ts destructures serviceTier but not collaborationMode, and the subsequent spawnSession({ ... }) call also omits it. That means Create Session → Collaboration = Plan reaches the hub but never becomes --collaboration-mode plan in buildCliArgs.

Suggested fix:

const { directory, sessionId, resumeSessionId, machineId, approvedNewDirectoryCreation, agent, model, effort, modelReasoningEffort, yolo, permissionMode, serviceTier, collaborationMode, token, sessionType, worktreeName } = params || {}

const result = await spawnSession({
    directory,
    sessionId,
    resumeSessionId,
    machineId,
    approvedNewDirectoryCreation,
    agent,
    model,
    effort,
    modelReasoningEffort,
    yolo,
    permissionMode,
    serviceTier,
    collaborationMode,
    token,
    sessionType,
    worktreeName
})

Create Session Plan was accepted by the hub but dropped in apiMachine
before buildCliArgs; also preserve collaborationMode on resume spawn.

Co-authored-by: Cursor <cursoragent@cursor.com>
@swear01

swear01 commented Jul 11, 2026

Copy link
Copy Markdown
Contributor Author

Fixed HAPI Bot Major: collaborationMode now forwarded in cli/src/api/apiMachine.ts (with regression test). Also pass it on hub resume spawn so Plan survives restart.

Co-authored-by: Cursor <cursoragent@cursor.com>

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  • [Minor] Fast mode selection can be reset while the Codex model catalog is still loading — showCodexFastMode is false whenever codexModelsState.models is empty, including the initial load. In the Browse → New Session remount path, the draft restores serviceTier: 'fast', then this effect immediately changes it back to standard before useCodexModels returns, so the spawn payload omits Fast even for models that advertise it. Evidence web/src/components/NewSession/index.tsx:217.
    Suggested fix:
    const hasCodexModelCatalog = codexModelsState.models.length > 0
    
    useEffect(() => {
        if (hasCodexModelCatalog && !showCodexFastMode && serviceTier !== 'standard') {
            setServiceTier('standard')
        }
    }, [hasCodexModelCatalog, showCodexFastMode, serviceTier])

Summary
Review mode: follow-up after new commits

  • Previous bot finding is fixed in the new commits; one remaining Minor issue affects preserving Fast mode during create-session draft restore.

Testing

  • Not run (automation; static review only).

HAPI Bot

&& codexModelAdvertisesFastTier(model === 'auto' ? null : model, codexModelsState.models)

useEffect(() => {
if (!showCodexFastMode && serviceTier !== 'standard') {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[MINOR] showCodexFastMode is false while useCodexModels is still loading because the catalog array is empty. In the Browse → New Session remount path, the draft can restore serviceTier: 'fast' and then this effect immediately resets it to standard before the catalog response arrives, so the create request later omits Fast even for a model that advertises it.

Suggested fix:

const hasCodexModelCatalog = codexModelsState.models.length > 0

useEffect(() => {
    if (hasCodexModelCatalog && !showCodexFastMode && serviceTier !== 'standard') {
        setServiceTier('standard')
    }
}, [hasCodexModelCatalog, showCodexFastMode, serviceTier])

Co-authored-by: Cursor <cursoragent@cursor.com>
@swear01

swear01 commented Jul 11, 2026

Copy link
Copy Markdown
Contributor Author

Addressed follow-up Minor: do not clear restored serviceTier: 'fast' while the Codex model catalog is still loading.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  • No issues found in the latest diff.

Summary
Review mode: follow-up after new commits

  • Reviewed the full current PR diff, using the prior HAPI Bot review and c1f81f8...9fe3fe9 compare diff as follow-up context.
  • The prior Fast-mode restore issue appears addressed by waiting for the Codex model catalog load before clearing serviceTier.
  • Residual risk: static review only; local test execution was unavailable in this environment.

Testing

  • Not run: bun is not installed in this runner environment (/bin/bash: bun: command not found).

HAPI Bot

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  • No issues found in the latest diff.

Summary
Review mode: follow-up after new commits

  • Reviewed the full current PR diff, using the previous HAPI Bot review and the 9fe3fe9...d8a1898 compare diff as follow-up context.
  • No high-confidence correctness, security, regression, data-loss, performance, or maintainability issues found in the added/modified lines.
  • Residual risk: static review only; focused route/UI behavior still depends on CI or a local Bun environment.

Testing

  • Not run (automation): bun is not installed in this runner environment.

HAPI Bot

…st-personality-plan

# Conflicts:
#	cli/src/api/apiMachine.test.ts
#	hub/src/web/routes/machines.ts
#	web/src/api/client.ts
#	web/src/components/NewSession/index.tsx
#	web/src/components/NewSession/newSessionFormDraft.ts
#	web/src/components/NewSession/types.ts
#	web/src/hooks/mutations/useSpawnSession.ts

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  • [Minor] Fast selection can be dropped while the Codex catalog is loading — showCodexFastMode is false while useCodexModels is still loading because the model list is empty, but the Create button remains enabled. A restored Browse draft can already have serviceTier === 'fast'; clicking Create before the catalog settles reaches web/src/components/NewSession/index.tsx:658 with showCodexFastMode === false, so the spawn payload omits serviceTier and starts Standard instead of the restored Fast choice.
    Suggested fix:
    const fastModeSelectionPending = agent === 'codex'
        && serviceTier === 'fast'
        && codexModelsState.isLoading
    
    const canCreate = Boolean(
        machineId
        && trimmedDirectory
        && !isFormDisabled
        && !missingWorktreeDirectory
        && !fastModeSelectionPending
    )

Summary
Review mode: follow-up after new commits

  • Reviewed the full current PR diff, using the previous HAPI Bot review and the prior-commit compare diff as follow-up context.
  • Found one static correctness issue in the new Create Session Fast-mode flow.
  • Residual risk: static review only; runtime UI behavior still depends on CI or manual browser validation.

Testing

  • Not run (automation): PR code treated as untrusted, so this pass did not execute tests.

HAPI Bot

const resolvedModelReasoningEffort = (agent === 'codex' || agent === 'opencode') && modelReasoningEffort !== 'default'
? modelReasoningEffort
: undefined
const resolvedServiceTier = agent === 'codex' && showCodexFastMode && serviceTier === 'fast'

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[MINOR] Fast selection can be dropped while the Codex catalog is loading

showCodexFastMode is false while useCodexModels is still loading because the model list is empty, but the Create button remains enabled. A restored Browse draft can already have serviceTier === 'fast'; clicking Create before the catalog settles reaches this line with showCodexFastMode === false, so the spawn payload omits serviceTier and starts Standard instead of the restored Fast choice.

Suggested fix:

const fastModeSelectionPending = agent === 'codex'
    && serviceTier === 'fast'
    && codexModelsState.isLoading

const canCreate = Boolean(
    machineId
    && trimmedDirectory
    && !isFormDisabled
    && !missingWorktreeDirectory
    && !fastModeSelectionPending
)

swear01 added a commit to swear01/hapi that referenced this pull request Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant