Skip to content

Python: Fix Windows Pyright errors for POSIX-only os flags in file_access sample - #9161

Merged
Jose Alvarez (jpalvarezl) merged 2 commits into
microsoft:mainfrom
jpalvarezl:jpalvarezl/fix-windows-sample-posix-flags
Oct 7, 2026
Merged

Jose Alvarez (jpalvarezl) merged 2 commits into
microsoft:mainfrom
jpalvarezl:jpalvarezl/fix-windows-sample-posix-flags

Conversation

@jpalvarezl

Copy link
Copy Markdown
Member

Motivation & Context

Windows Pyright reports six reportAttributeAccessIssue errors in
python/samples/04-hosting/foundry-hosted-agents/responses/files/file_access.py
because os.O_DIRECTORY, os.O_NOFOLLOW, and os.O_NONBLOCK are absent
from the Windows type stubs, even though the sample only ever executes its
POSIX descriptor-relative code path (it already fails closed with a
RuntimeError on platforms that lack these flags). This blocks
uv run poe pyright -S on Windows contributor/CI machines.

Description & Review Guide

  • What are the major changes? Replace the three literal os.O_NOFOLLOW /
    os.O_DIRECTORY / os.O_NONBLOCK attribute references with a small
    _posix_flag(name) helper that looks the flag up via getattr(os, name, None)
    and raises the same RuntimeError as before when it is missing. The prior
    hasattr guard in _directory_flags is replaced by this helper, and the two
    other call sites (_read_file, write_local_upload) now go through it as well.
  • What is the impact of these changes? Purely a static-analysis fix; runtime
    behavior is unchanged. No-follow, descriptor-relative opens, and the existing
    fail-closed guard are fully preserved — a missing flag still raises before any
    file I/O is attempted.
  • What do you want reviewers to focus on? Confirming the getattr-based
    lookup doesn't weaken the POSIX security checks (no-follow / dir_fd requirements)
    and still fails closed identically to the previous hasattr guard.

Related Issue

Fixes #

Contribution Checklist

  • The code builds clean without any errors or warnings
  • All unit tests pass, and I have added new tests where possible
  • The PR follows the Contribution Guidelines
  • This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
  • This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

Replace literal os.O_DIRECTORY/os.O_NOFOLLOW/os.O_NONBLOCK references in the
foundry-hosted-agents responses file_access sample with a small getattr-based
_posix_flag() helper. These flags are absent from the Windows type stubs, so
Pyright failed with reportAttributeAccessIssue on Windows even though the
sample only ever executes the POSIX code path. The helper still fails closed
at runtime (raises RuntimeError when a flag is missing), preserving the
existing no-follow/descriptor-relative security guarantees.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI balanced review requested due to automatic review settings October 7, 2026 15:30
@agent-framework-automation agent-framework-automation Bot added the python Usage: [Issues, PRs], Target: Python label Oct 7, 2026
@github-actions github-actions Bot changed the title Fix Windows Pyright errors for POSIX-only os flags in file_access sample Python: Fix Windows Pyright errors for POSIX-only os flags in file_access sample Oct 7, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🟢 Approval recommended

The implementation preserves secure behavior, with only a minor diagnostic wording issue noted.

1 open finding
What changed in this PR

Replaces direct POSIX-only os flag access with runtime lookup to keep Windows Pyright checks clean while preserving fail-closed file access.

Changes:

  • Adds _posix_flag for guarded flag lookup.
  • Updates directory, read, and write flags to use the helper.
File Description
python/​samples/​04-hosting/​foundry-hosted-agents/​responses/​files/​file_access.py Resolves POSIX flags dynamically while retaining security checks.

🧠 Review effort: Balanced


💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

Comment thread python/samples/04-hosting/foundry-hosted-agents/responses/files/file_access.py Outdated

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

MAF Automated Review — Iteration 1

Result: No findings
Scope: full PR (1 commit(s)): f12bf2fa2052
Model: gpt-5.6-sol

Overview

The PR replaces direct references to POSIX-only flags with a private dynamic lookup so Windows Pyright can analyze the sample. Missing flags still raise before file I/O, while descriptor-relative opens, no-follow behavior, non-blocking opens, file-type checks, and descriptor cleanup remain intact. No new publishable Critical, High, or Medium issue was established.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
@jpalvarezl
Jose Alvarez (jpalvarezl) added this pull request to the merge queue Oct 7, 2026
Merged via the queue into microsoft:main with commit 40763be Oct 7, 2026
43 checks passed
@jpalvarezl
Jose Alvarez (jpalvarezl) deleted the jpalvarezl/fix-windows-sample-posix-flags branch October 7, 2026 15:51

This branch was previously deployed

1 inactive deployment
github-app-auth — e5ec135d Deployed Oct 7, 2026 by jpalvarezl via add_label #24686
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

python Usage: [Issues, PRs], Target: Python

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants