feat: recording gate observability + user feedback

[Jasonnnz]

Summary

• Add structured log at CU session initialization with all QA/recording metadata (sessionId, qaMode, requiresRecording, targetAppName, targetAppBundleId, recordingGateStatus)
• Enhance destructive action blocking log with additional context (requiresRecording, stepCount)
• Add full session context to recording handshake timeout error log (recordingGateStatus, requiresRecording, targetAppName, targetAppBundleId, stepCount)
• Improve timeout error message to be user-actionable: includes duration, diagnosis hint, and System Settings path for screen recording permissions
• Improve recording failure abort message to include specific error reason and QA session context
• Log recording gate status transitions with previousStatus/newStatus in the handler
• Increase Swift overlay recording error text maxHeight from 60 to 80 to accommodate longer error messages
• Enable .textSelection(.enabled) on recording warning text so users can copy error details

Test plan

• Verify daemon logs CU session initialized with all metadata fields when a new CU session is created
• Verify recording gate status transitions log Recording gate status changed with previous/new status
• Verify destructive action blocking log includes requiresRecording and stepCount
• Verify recording handshake timeout produces user-friendly error message with System Settings hint
• Verify recording failure abort message includes the specific failure reason
• Verify Swift overlay shows error text without truncation in the expanded 80pt container
• Verify recording warning text is selectable in the Swift overlay

🤖 Generated with Claude Code

---

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7403096117

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Derive qaMode from QA flag, not recording requirement

The new initialization log sets qaMode to !!requiresRecording, but QA sessions are not always recording-gated (for example, requiresRecording is only set when config.qaRecording.enforceStartBeforeActions is enabled in assistant/src/daemon/handlers/shared.ts:277-299). When that flag is off, real QA sessions will now be logged as qaMode: false, which undermines the observability this commit is trying to improve and makes QA incident triage misleading.

Useful? React with 👍 / 👎.

[devin-ai-integration]

Devin Review found 1 potential issue.

View 4 additional findings in Devin Review.

[devin-ai-integration]

🟡 qaMode log field incorrectly derived from requiresRecording instead of actual qaMode

The new constructor log at line 147 computes qaMode: !!requiresRecording, but qaMode and requiresRecording are independent fields in the IPC contract (assistant/src/daemon/ipc-contract.ts:183 and assistant/src/daemon/ipc-contract.ts:189). The ComputerUseSession constructor never receives the actual qaMode value from the CuSessionCreate message.

Root Cause

In assistant/src/daemon/handlers/computer-use.ts:89-102, the handler creates a ComputerUseSession passing msg.requiresRecording but not msg.qaMode. The constructor then logs qaMode: !!requiresRecording as a proxy. However, a session can be in QA mode (msg.qaMode: true) without requiring recording (msg.requiresRecording: undefined), making the logged qaMode value false when it should be true. This produces misleading structured logs that will confuse debugging of QA session initialization — the exact scenario this PR is trying to improve observability for.

Impact: Incorrect qaMode field in structured logs. Operators filtering/alerting on qaMode in the CU session initialized log entry will get wrong results.

Prompt for agents

The qaMode field in the log at assistant/src/daemon/computer-use-session.ts:147 is derived from requiresRecording, but qaMode is a separate IPC field. Either:
1. Pass qaMode as a separate constructor parameter (from msg.qaMode in assistant/src/daemon/handlers/computer-use.ts:89-102) and log it directly, OR
2. Remove the qaMode field from this log since the constructor doesn't have access to it, and rely on the existing log in the handler at line 124 which could be enhanced to include qaMode from msg.qaMode.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[Jasonnnz]

Addressed in #7462