feat(mobile): add Codex task parity

[richardsolomou]

Problem

Mobile task creation hardcoded Claude, and its new-task and conversation screens had drifted from desktop. Runtime choices could also be lost or mapped to Claude-specific configuration when retrying or resuming Codex tasks.

Changes

I added Claude and Codex controls across task creation, retry, and resume using the shared model and reasoning policies. Adapter-specific execution modes, defaults, and cloud reasoning keys now come from core. Native rendering remains in mobile.

How did you test this?

• Ran the full shared, API client, core, and mobile test suites.
• Ran the monorepo typecheck.
• Ran repo-wide Biome and the host-boundary check.
• Tested real Claude and Codex task-detail screens, failed-run states, and PR actions in the iPhone simulator.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[github-actions]

React Doctor found 2 issues in 2 files · 2 warnings.

2 warnings

src/app/task/index.tsx

• ⚠️ src/app/task/index.tsx:226 Event logic handled in an effect no-event-handler

src/features/tasks/composer/TaskChatComposer.tsx

• ⚠️ src/features/tasks/composer/TaskChatComposer.tsx:157 Event logic handled in an effect no-event-handler

_{Reviewed by React Doctor for commit 29a77af.}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/core/src/sessions/cloudTaskSessionService.ts:402
**Legacy Resume Drops Task Controls**

When both the legacy run and its persisted composer config lack an adapter, this remains `undefined`. The mobile API client then omits the resolved model, reasoning, and permission mode with the adapter, so retry can restart an older Claude task using server defaults instead of its previous controls.

```suggestion
    const adapter =
      composerConfig?.adapter ?? previousRun?.adapter ?? "claude";
```

### Issue 2 of 2
packages/core/src/sessions/cloudTaskSessionService.ts:425-428
**Invalid Run Reasoning Reused**

When the composer reasoning is unsupported and the adapter has not changed, this fallback reuses `previousRun.reasoningEffort` without validating it. If that stored value is also unsupported by the resolved model, the API client rejects the payload and sandbox-inactive retry fails instead of resuming.

_{Reviews (1): Last reviewed commit: "feat(mobile): add Codex task controls" | Re-trigger Greptile}

[greptile-apps]

Legacy Resume Drops Task Controls

When both the legacy run and its persisted composer config lack an adapter, this remains undefined. The mobile API client then omits the resolved model, reasoning, and permission mode with the adapter, so retry can restart an older Claude task using server defaults instead of its previous controls.

Suggested change

	const adapter = composerConfig?.adapter ?? previousRun?.adapter;
	const adapter =
	composerConfig?.adapter ?? previousRun?.adapter ?? "claude";

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/core/src/sessions/cloudTaskSessionService.ts
Line: 402

Comment:
**Legacy Resume Drops Task Controls**

When both the legacy run and its persisted composer config lack an adapter, this remains `undefined`. The mobile API client then omits the resolved model, reasoning, and permission mode with the adapter, so retry can restart an older Claude task using server defaults instead of its previous controls.

```suggestion
    const adapter =
      composerConfig?.adapter ?? previousRun?.adapter ?? "claude";
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Invalid Run Reasoning Reused

When the composer reasoning is unsupported and the adapter has not changed, this fallback reuses previousRun.reasoningEffort without validating it. If that stored value is also unsupported by the resolved model, the API client rejects the payload and sandbox-inactive retry fails instead of resuming.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/core/src/sessions/cloudTaskSessionService.ts
Line: 425-428

Comment:
**Invalid Run Reasoning Reused**

When the composer reasoning is unsupported and the adapter has not changed, this fallback reuses `previousRun.reasoningEffort` without validating it. If that stored value is also unsupported by the resolved model, the API client rejects the payload and sandbox-inactive retry fails instead of resuming.

How can I resolve this? If you propose a fix, please make it concise.