[Bug]: iOS notification opened from Usage leaves bottom navigation covering the composer #31062

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

1. On iPhone, open T3 Code and select the Usage tab.
2. Background the app.
3. Receive a notification for a thread.
4. Tap the notification to open the thread.

The reporter reproduced this on their phone after investigating the intermittent overlap.

Expected behavior

The thread opens with the composer fully visible and accessible, with the workspace navigation in a consistent state.

Actual behavior

The thread opens, but Usage remains selected. The bottom navigation controls remain visible over the composer, blocking access to the chatbox.

Impact

Major degradation or frequent failure: the composer is obstructed when this state occurs. The failure is conditional on opening the notification from Usage; it is not claimed to happen on every notification tap.

Version or commit

Affected mobile app version/build was not captured. Code diagnosis below is based on checkout 9e85538; this is not a claim that the phone runs that commit.

Environment

iPhone, native T3 Code iOS app. Exact iPhone model, iOS version, and connection mode were not captured.

Logs or stack traces

None captured.

Screenshots, recordings, or supporting files

No attachments included.

Workaround

None confirmed.

Suspected cause and possible fix direction

The reproduction above was confirmed by the reporter on a phone. The following diagnosis comes from code inspection; no patch has been implemented or verified:

• Notification taps go through installAgentNotificationNavigation(linkToAppPath) in apps/mobile/src/App.tsx, then workspaceDetailLinkAction and SELECT_WORKSPACE_DETAIL. This updates routes without updating the selected workspace tab.
• Normal thread selection through handleSelectDetail in apps/mobile/src/features/layout/AdaptiveWorkspaceLayout.tsx also dispatches workspace tab selection.
• In apps/mobile/src/features/layout/createWorkspaceStackNavigator.ios.tsx, workspacePage is derived from the selected tab. It remains true for Usage, and the hidden prop passed to WorkspaceNativeTabs requires !workspacePage.
• apps/mobile/src/features/workspace/WorkspaceNativeTabs.ios.tsx consequently keeps its absolutely positioned footer visible over the thread composer.

Consider keeping workspace tab selection consistent when a thread opens through notification/deep-link navigation, as normal thread selection already does. A fix should be checked on a device because changing the tab moves content between retained native tab slots. Relevant checks include background and cold-start notification taps, composer/keyboard interaction, Back and swipe-back, restoration of the bottom controls, and iPad layout.

Related reports

• [Bug]: iPad: bottom tab bar covers the prompt field when the sidebar is closed or the window is narrow #27007: bottom tab bar covers the prompt field on iPad when the sidebar is closed or the window is narrow. Similar overlap, different trigger.
• [Bug]: Tapping an iOS approval notification doesn't open the thread waiting for approval #26544: an iOS approval notification fails to open its thread. Here the thread opens, but the controls overlap it.
• [Bug]: Tapping Dynamic Island Live Activity restores last visited thread instead of target thread #18997 (closed): Dynamic Island opens the wrong thread, a different routing symptom.

Report prepared with Codex (gpt-6.1-sol), with investigation and drafting assistance from Claude Opus 5.5 through T3 Code.