[Windows][Desktop][Automations] Scheduled heartbeat drops the selected named permission profile and sends legacy sandboxPolicy instead #50120

Summary

On Windows, a heartbeat automation targeting an existing local-project thread can replace the selected named permission profile with a generic approval mode.

My threads are configured to use the named permission profile youtube-pi-dev. After affected scheduled runs, the UI changes from that profile to the Japanese label 代わりに承認.

For one affected thread, the captured execution logs also show that:

• active_permission_profile disappears.
• The recorded filesystem permission definition changes.
• An explicit write entry for the project directory is no longer present.
• approval_policy and approvals_reviewer remain unchanged.

A read-only investigation of the installed application's bundled JavaScript identified a likely cause: the heartbeat request-construction path receives the saved named profile but does not forward its ID. Instead, it explicitly sends the legacy sandboxPolicy to turn/start.

No proposed fix has been applied to the installed application. The original reproduction and the additional observation on October 2 occurred without applying the proposed patch.

Environment

• Operating system: Windows 11
• Installed app package: OpenAI.Codex
• Desktop app version inspected: 26.928.3736.0
• Application code collected: October 2, 2026, approximately 01:21 JST
• CLI version recorded in the affected thread's session_meta: 0.159.2
• Local project directory: D:\program_works\python\youtube_pi_agent_gui
• Named permission profile: youtube-pi-dev
• Profile inheritance: :workspace
• Approval policy in the compared records: on-request
• Approvals reviewer in the compared records: auto_review
• Automation type: heartbeat, targeting an existing thread
• Schedule for the directly investigated automation: every 30 minutes

The 0.159.2 value above comes from recorded session metadata. It is not a separately verified identification of every runtime process active during the investigation.

The project configuration contains default_permissions = "youtube-pi-dev", and the project is marked as trusted. The named profile is defined in the configuration and is present in normal/manual turn records.

Expected behavior

A heartbeat automation targeting a thread should preserve the named permission profile selected for that thread, including its identity and intended permissions, subject to applicable managed restrictions.

For a thread using youtube-pi-dev, the scheduled request should preserve that selection through permissions: "youtube-pi-dev" or an equivalent supported mechanism.

It should not silently replace the named profile with a legacy sandbox-policy representation that does not retain the profile identity and may produce a different permission definition.

Actual behavior and captured evidence

Persisted selection

At the time of capture, the desktop's heartbeat-thread-permissions-by-id state still contained the named profile for the affected thread, even though intervening execution records lacked it.

The following is the captured entry with the Windows username and thread ID redacted:

{
  "activePermissionProfile": {
    "id": "youtube-pi-dev",
    "extends": ":workspace"
  },
  "approvalPolicy": "on-request",
  "approvalsReviewer": "auto_review",
  "sandboxPolicy": {
    "type": "workspaceWrite",
    "writableRoots": [
      "C:\\Users\\<USER>\\.codex\\visualizations\\2026\\10\\01\\<THREAD_ID>"
    ],
    "networkAccess": true,
    "excludeTmpdirEnvVar": false,
    "excludeSlashTmp": false
  }
}

This shows that the named selection was present in the captured desktop state. It does not establish that every in-memory state was identical at every execution boundary.

Execution-context comparison

The following two records come from the same affected thread on October 1, 2026. All times are JST, UTC+09:00.

The legacy writable_roots list was the same, but the complete legacy policy was not identical because the temporary-directory flags also changed.

Representative records from that thread show the following pattern:

2026-10-01 17:02:15 JST — active_permission_profile = youtube-pi-dev
2026-10-01 17:16:41 JST — active_permission_profile field absent
2026-10-01 17:17:25 JST — active_permission_profile = youtube-pi-dev
2026-10-01 17:46:41 JST — active_permission_profile field absent
2026-10-01 18:16:51 JST — active_permission_profile field absent
2026-10-01 18:21:09 JST — active_permission_profile = youtube-pi-dev

The recurring approximately 30-minute pattern is consistent with the automation schedule. However, not every record in this timeline has been individually correlated with a captured live request, so the timeline alone should not be treated as proof of the trigger for every entry.

Scope of the observed impact

The logs establish a change in the recorded filesystem permission definition, not an operating-system access test.

In particular:

• The loss of the explicit project write entry was recorded.
• Actual OS-level write denial was not tested as part of this investigation.
• The disappearance of an explicit read entry for the Python installation does not prove that Python became unreadable, because a broader root-read entry remained.
• Network enablement and per-domain authorization were not treated as equivalent. Loss of all configured domain permissions has not been demonstrated.
• No sandbox escape or privilege escalation has been demonstrated.

Reproduction pattern

This describes the pattern observed in my existing environment, not a verified clean-install minimal reproducer.

1. Use a trusted local project with a valid named permission profile.
2. Select that profile for an existing thread.
3. Confirm that a normal/manual turn records the intended active_permission_profile.
4. Configure a heartbeat automation targeting the same thread.
5. Let the automation run on schedule.
6. Compare the UI selection and the resulting turn_context with the preceding named-profile turn.

Multiple threads in the same project have exhibited the UI symptom. Detailed before/after execution-context evidence was collected for one affected thread.

The exact conditions distinguishing an affected run from a run that retains the profile are not yet established. I am not claiming that every scheduled execution fails.

Additional observation on October 2: the previously unaffected main thread also changed

Initially, one older “main” thread appeared to retain youtube-pi-dev, while other threads exhibited the problem.

On the morning of October 2, 2026, JST, I also observed the permission selection change in that main thread.

At that time:

• The proposed application fix had not been applied.
• No post-fix real-device validation had been performed.

This is therefore an additional observation in an unpatched environment, not a regression caused by the proposed patch.

The main thread should no longer be described as an unaffected exception.

For this additional main-thread observation, the exact scheduled run, outgoing request, and resulting turn_context have not yet been correlated. I am reporting the observed selection change, not claiming that its detailed filesystem policy was separately verified.

The older main thread's captured working directory was under the previous C: location, whereas other affected threads used the D: location. This difference has not been established as the cause or a reliable workaround. The morning observation also shows that the older thread is not reliably protected from the symptom.

Technical investigation

The installed application's app.asar was read without modifying the installed application.

The investigation used the complete collected JavaScript modules and traced the heartbeat request path through final JSON serialization. This was an AI-assisted analysis, with an isolated request-packaging test described below.

1. The heartbeat entry point drops the named selection

File:

.vite/build/main-DkWgQSQe.js

Function: Jl

The following is the complete function, formatted for readability while retaining the bundled identifiers:

async function Jl({
    statsig: e,
    automation: t,
    thread: n,
    appServerConnection: r,
    collaborationMode: i,
    permissions: a,
    waitForCompletion: o,
    runTrigger: s
}) {
    let c = await Yl({
            thread: n,
            appServerConnection: r
        }),
        l = a ?? await Zl({
            appServerConnection: r,
            cwd: c.cwd
        }),
        u = Ql(t);

    await iu({
        automation: t,
        appServerConnection: r,
        sessionId: c.sessionId,
        threadId: c.id,
        cwd: c.cwd,
        prompt: u,
        collaborationMode: i,
        approvalPolicy: l.approvalPolicy,
        approvalsReviewer: l.approvalsReviewer,
        sandboxPolicy: l.sandboxPolicy,
        model: null,
        effort: null,
        cyberAccessProgram: await Xl(r, c, e),
        waitForCompletion: o,
        runTrigger: s
    });
}

The incoming saved permissions object can contain activePermissionProfile, but Jl forwards only approvalPolicy, approvalsReviewer, and sandboxPolicy from that object.

It does not forward the profile ID.

It also does not forward runtimeWorkspaceRoots when that field is present.

2. The downstream heartbeat path does not restore the missing ID

In the same file:

• iu constructs the turn-start request with sandboxPolicy, without a named permissions field.
• au, used for the completion-waiting branch, forwards that request without restoring the named profile.

The traced connection-side path continues through:

.vite/build/main-DkWgQSQe.js
  Jl
    -> iu / au

.vite/build/bootstrap-DvSEn4qy.js
  TN.startTurn
    -> mM.startTurn
    -> TN.sendInternalRequest
    -> Rj.sendMessage
    -> JSON serialization / transport

The metadata and compatibility transformations on this path did not add the missing profile ID.

This is distinct from the ordinary message-submission path involving $ue.startTurn, eue, and Yle / prepare. The existence of settings inheritance on that ordinary path does not establish that the heartbeat request receives the same supplementation.

3. The bundle already contains a named-profile/legacy-policy conversion helper

File:

.vite/build/src-ghAWefM3.js

Function: qn, exported as pa

Complete function:

function qn(e) {
    return e.activePermissionProfile == null
        ? { sandboxPolicy: e.sandboxPolicy }
        : { permissions: e.activePermissionProfile.id };
}

This helper sends the profile ID when a named selection exists, and the legacy sandbox policy otherwise.

The investigated heartbeat Jl -> iu path does not perform this distinction.

4. Comparison with the public runtime source

The public rust-v0.159.2 tag was inspected because it matches the version string recorded in the affected thread's session metadata.

The relevant source behavior is:

• TurnRequestProcessor::build_thread_settings_overrides rejects simultaneous permissions and sandboxPolicy.
• When permissions is supplied, the named profile is resolved using the thread configuration and working directory.
• SessionConfiguration::apply has a separate legacy-policy path when a sandbox_policy override is supplied without a permission_profile.
• That path calls set_legacy_permission_profile, which installs a legacy permission-profile snapshot.

References:

• https://github.com/openai/codex/blob/rust-v0.159.2/codex-rs/app-server/src/request_processors/turn_processor.rs
• https://github.com/openai/codex/blob/rust-v0.159.2/codex-rs/core/src/session/session.rs
• https://github.com/openai/codex/blob/rust-v0.159.2/codex-rs/core/src/config/resolved_permission_profile.rs

The running native binary was not compared byte-for-byte with that public source version. This comparison supports the diagnosis but is not a complete verification of every runtime behavior on the affected machine.

Isolated request-construction tests

An isolated test harness used the extracted application functions, with thread-resume responses, transport, notifications, and related dependencies replaced by test doubles.

The investigation compared:

• 32 cases using the original request-construction code.
• 32 cases using a proposed correction.

All 64 cases passed their respective assertions. For the original-code cases, those assertions included confirming the missing profile ID; they do not mean that the original behavior was correct.

The combinations covered scheduled versus “run now” invocation, mocked compatibility branches, the presence or absence of runtime workspace roots, and named-profile versus legacy inputs.

Representative results:

These tests validate request packaging only. They do not constitute a Windows application reproduction, a test of the native runtime, an OS sandbox test, or proof that the proposed fix resolves every execution condition.

Suggested fix direction

Preserve the selected named profile throughout heartbeat request construction.

When a valid saved activePermissionProfile exists, pass its ID using permissions and do not simultaneously send sandboxPolicy.

When no named profile exists, retain the appropriate legacy behavior.

Please also review:

• The fallback path when saved thread permissions are unavailable.
• Cold-resume and existing-thread state interactions.
• Whether existing runtimeWorkspaceRoots need to be preserved without replacing an absent value with an empty list.
• Scheduled and “run now” execution, as well as regression coverage for ordinary manual turns.

The correction should retain the existing approval policy, approvals reviewer, model settings, input, notification behavior, completion handling, and applicable restrictions.

The proposed local correction targets Jl and iu, but it has not been applied to the installed application and has not received real-device validation.

Diagnostic material and current status

Available diagnostic material includes:

• The relevant original bundled JavaScript from app version 26.928.3736.0.
• Captured persisted permission-state entries.
• Before/after execution-context records and a permission timeline.
• A proposed correction.
• The isolated request-packaging test results.

Redacted supporting material can be provided through an appropriate support channel.

Current status:

• Request-construction omission identified in the inspected application code.
• Detailed permission-definition changes recorded for an affected thread.
• Additional UI occurrence observed in the previously unaffected main thread.
• No proposed fix applied to the installed application.
• No post-fix real-device or scheduled-run validation completed.