AzDO triage report 2026-05-27 to 2026-06-16 (6 open items)

[StellaHuang95]

6 open work item(s) with activity in the past 20 day(s) under DevDiv\Python and AI Tools\**.

• AzDO #2799103 — Open tabbed files not reappearing when VS2026 is restarted — created 2026-03-05 — area: Python
• AzDO #2859765 — Python debugging failure with Python 3.14.3 — created 2026-03-26 — area: Python
• AzDO #2966850 — Subject: Python Indexing Failure: Navigation Bar and Solution Explorer Sync Issues (v18.5.1) — created 2026-04-24 — area: Python\Language Server
• AzDO #2966873 — Python Interactive Window: Illegible Default Syntax Highlighting (Dark Blue on Black) — created 2026-04-24 — area: Python
• AzDO #3009676 — How can I change the max line lenght of the Python formatting in VS 2022 ? — created 2026-05-30 — area: Python\VS IDE
• AzDO #3018151 — return files from my computer — created 2026-06-16 — area: Python\VS IDE

---

Generated by AzDO Pipeline PTVS-Triage-Fetch. run details.

[StellaHuang95]

Triage analysis for AzDO #2799103

Root cause category: Upstream
Confidence: Medium

Diagnosis

The reported behavior — open editor tabs not being restored after a Visual Studio restart — is managed by the Visual Studio shell's window layout and session-persistence subsystem (specifically the Running Document Table and the IDE's window-frame serialization), not by PTVS. PTVS does not own tab-restore logic; it only participates by registering document factories and responding to open-document requests from the shell.

The ticket is tagged Acquisition and includes multiple VS installer (dd_setup_*, dd_installer_*) logs, suggesting the real investigation focused on whether a fresh installation of the Python Development workload was complete and correct — not on a PTVS editor code bug. The work item was already closed as Not a Bug by the DC team, consistent with this being a VS platform behavior difference between VS 2022 and VS 2026 rather than a PTVS regression.

No PythonToolsDiagnostics_*.log was attached, so there is no PTVS-side exception evidence. A search of the PTVS repo found no open issues or recent PRs dealing with tab/window-layout restoration.

Evidence from repo

• Common/Product/SharedProject/FileDocumentManager.cs — PTVS's document manager opens files on request from the VS shell but contains no tab-persistence or session-restore logic; that layer is entirely upstream.

Related issues / PRs

(None found that are clearly related.)

Suggested customer response

Thank you for the detailed report and for following up with the installer logs. The behavior you're seeing — open editor tabs not reappearing after restarting Visual Studio — is controlled by Visual Studio's own window-layout and session-restore system rather than by the Python Tools extension itself.

A few things that may help:

• Go to Tools → Options → Environment → Startup and verify "Reopen documents on solution load" or the equivalent setting is enabled for your configuration.
• Try Window → Reset Window Layout and then restart, as a corrupt layout file can prevent tabs from being restored.
• If the issue persists, please report it at Developer Community (VS) under the Visual Studio > IDE category so the Visual Studio shell team can investigate.

We don't see evidence that the Python Tools extension is the cause here, but we appreciate you taking the time to share the diagnostics.

Recommended maintainer action: Out of scope / not actionable

[StellaHuang95]

Triage analysis for AzDO #2859765

Root cause category: Upstream
Confidence: High

Diagnosis

The failure is in debugpy's vendored pydevd component — specifically in _pydevd_sys_monitoring/_pydevd_sys_monitoring.py, function is_thread_alive. That code unconditionally calls self.thread._handle.is_done(), but CPython 3.14 removed the private _handle attribute from threading.Thread (it was internal implementation detail previously used to check thread liveness). The result is an AttributeError: '_handle' that surfaces as a debug-session crash before any user code runs.

The file in question is not part of the PTVS source tree in microsoft/PTVS; it lives entirely within the bundled debugpy wheel. PTVS ships debugpy as a binary package (currently tracked at version 1.8.21 in Build/debugpy-version.txt). The fix must come from microsoft/debugpy upstream, where the _pydevd_sys_monitoring.py is_thread_alive guard needs to be made Python-version-aware or use a supported public API (e.g., thread.is_alive()).

PR #8300 (merged Oct 2025) added Python 3.14 recognition in PTVS (version detection, attach tests, build tooling), but it did not update the bundled debugpy wheel to a version that contains the threading fix. If debugpy 1.8.x upstream has already shipped a patch for this, PTVS just needs to pick up the newer wheel.

The user's temporary workaround (hasattr(self.thread, '_handle')) is directionally correct but incomplete; the proper fix should fall back to thread.is_alive() rather than returning 1 (truthy always), which would cause alive-threads to be incorrectly treated as done.

Evidence from repo

• Build/debugpy-version.txt:L1 — bundled debugpy pinned at 1.8.21; cgmanifest.json shows an older entry of 1.4.3 (stale), confirming version tracking lives in the txt file
• Python/Product/Common/Parsing/PythonLanguageVersion.cs — modified in PR add and python 3.14 and upgrade examples to 145 build tools  #8300 to recognize Python 3.14, but no debugpy wheel bump occurred in that PR

Related issues / PRs

• add and python 3.14 and upgrade examples to 145 build tools  #8300 — Merged PR adding Python 3.14 version recognition and attach tests; did not include a debugpy wheel update addressing the _handle regression
• [Not checking in] Add python314 support #8299 — Companion (not-checked-in) PR with extended Python 3.14 safe-attach design notes; confirms 3.14 debugging work was active but scoped to PTVS-side attach, not the debugpy threading bug

Suggested customer response

Thank you for reporting this and for the detailed workaround — that's very helpful!

The crash originates in the debugpy library that Visual Studio bundles for Python debugging. In Python 3.14, a private internal attribute (_handle) was removed from threading.Thread, and the version of debugpy currently shipped with Visual Studio 2022 17.14 accesses that attribute unconditionally, causing the AttributeError you're seeing.

This is a known compatibility gap between debugpy and Python 3.14. The fix needs to land in debugpy itself (https://github.com/microsoft/debugpy), and then be picked up by a future Visual Studio update.

In the meantime, your workaround modifying the local _pydevd_sys_monitoring.py file is reasonable, though note that VS updates may overwrite it. A slightly safer fallback would be:

if hasattr(self.thread, '_handle'):
    return not self.thread._handle.is_done()
return self.thread.is_alive()

We appreciate you taking the time to investigate and share the exact location of the issue.

Recommended maintainer action: Investigate further — verify whether a debugpy release newer than 1.8.21 already contains this fix, and if so, schedule a wheel bump. If not, file a bug in microsoft/debugpy referencing this ticket.

[StellaHuang95]

Triage analysis for AzDO #2966850

Root cause category: Upstream
Confidence: Medium

Diagnosis

The reported behavior — Navigation Bar symbols not refreshing after editing a Python file, requiring a close/reopen to update — is consistent with a language server (Pylance) issue rather than a PTVS code path. The Navigation Bar for Python in Visual Studio is driven by LSP textDocument/documentSymbol responses from the language server; PTVS itself only exposes the navigation bar preference toggle (fDropdownBar) and does not own the symbol-refresh pipeline.

The DC item is already closed as Duplicate on the developer community side, suggesting this has been previously reported. There is no diagnostics log attached, so PTVS version, VS version, and exception traces are unknown. The user reports regression from VS 2022 → VS 2026 (18.5.1), which points to a change in Pylance or the VS editor platform's LSP integration rather than a PTVS regression.

There is a long-standing open issue (#6551) tracking the Navigation Bar not working reliably for Python, which is assigned and under investigation. Issue #8121 also covers navigation dropdown inconsistency. These are the most likely duplicate targets.

No PTVS-owned symbol-refresh or save-triggered re-index code was found that would explain stale Navigation Bar entries; the relevant PTVS file only surfaces the preference bit.

Evidence from repo

• Python/Product/PythonTools/PythonTools/Editor/LanguagePreferences.cs:L119 — public bool NavigationBar => _preferences.fDropdownBar != 0; PTVS only exposes a preference flag; no symbol-refresh logic found here.

Related issues / PRs

• Navigation bar is not working #6551 — "Navigation bar is not working" — open bug (P2) directly tracking Navigation Bar failures for Python, assigned to a team member
• Features not working consistently: task list, navigation dropdown menus #8121 — "Features not working consistently: task list, navigation dropdown menus" — reports the same intermittent navigation dropdown problem across VS 2022 releases
• Make navigation bar work with Python symbols #7661 — "Make navigation bar work with Python symbols" — closed feature request showing the navigation bar's limited Python symbol support is a known gap

Suggested customer response

Thank you for reporting this! The behavior you're describing — where the Navigation Bar and Solution Explorer continue to show deleted functions until the file is closed and reopened — is a known issue we're tracking.

Symbol refresh in the Navigation Bar for Python files is driven by the Python language server, and we have an open investigation into cases where it doesn't update reliably in real time. Your report matches a pattern we've seen from other users.

Unfortunately we don't have a timeline to share for a fix, but your feedback has been noted and helps prioritize this work. In the meantime, saving the file and then switching away and back to it (rather than fully closing) may trigger a refresh in some cases.

Thank you for taking the time to report this with clear reproduction steps!

Recommended maintainer action: Close as duplicate of #6551

[StellaHuang95]

Triage analysis for AzDO #2966873

Root cause category: PTVS
Confidence: High

Diagnosis

The Python Interactive Window (REPL) output classifier in PTVS maps System.ConsoleColor ANSI color codes to hard-coded absolute RGB ClassificationFormatDefinition entries. These definitions — e.g., InteractiveDarkBlueFormatDefinition (#00007F) and InteractiveBlueFormatDefinition (#0000FF) — were written for a light-background context and are completely opaque, absolute values with no theme-awareness. On a dark VS theme the same dark-blue values render nearly invisible against a black background.

InteractiveBlackFormatDefinition is even worse: it sets ForegroundColor = Colors.Black unconditionally, which is invisible on any dark editor background. When the Python REPL sends output that uses ConsoleColor.DarkBlue (common for keywords/identifiers in syntax-highlighted REPL output from IPython or similar shells), the text is painted #00007F on a near-black background — exactly the "deep cobalt blue" the reporter describes.

The secondary observation — "Python Interactive" missing from the Fonts & Colors dropdown — is consistent with these format definitions not being scoped to a dedicated "Python Interactive" category in the VS color registry; instead they appear under generic names and may not surface as a distinct group in some VS configurations.

The ticket is tagged as a regression from VS 2022 → VS 2026. The color definitions themselves have not changed recently in the repo, so the regression is more likely a change in what ANSI colors the REPL evaluator (or an upstream component like the IVsInteractiveWindow host) applies by default in the new VS version — causing DarkBlue tokens to become newly prominent.

Evidence from repo

• Python/Product/PythonTools/PythonTools/Repl/ReplOutputClassificationFormatDefinitions.cs:L30-L41 — InteractiveBlackFormatDefinition sets ForegroundColor = Colors.Black (invisible on dark theme); InteractiveDarkBlueFormatDefinition (L102–L113) sets ForegroundColor = Color.FromRgb(0x00, 0x00, 0x7f) — a hardcoded dark-blue with no theme override.
• Python/Product/PythonTools/PythonTools/Repl/ReplOutputClassifierProvider.cs:L36 — ConsoleColor.DarkBlue maps directly to InteractiveDarkBlueFormatDefinition, confirming ANSI DarkBlue output will be rendered #00007F regardless of theme.
• Python/Product/PythonTools/PythonTools/Repl/ReplOutputClassifier.cs:L59-L74 — The classifier reads ConsoleColor values from buffer properties (set by the evaluator) and dispatches to the absolute-color format definitions above.

Related issues / PRs

• LSC: Syntax colorization in interactive window #5872 — "LSC: Syntax colorization in interactive window" — prior work on colorization in the Interactive Window; shows this area has a known history of colour-related gaps.
• LSC Prototype: Content type / colorization in interactive window #5674 — "LSC Prototype: Content type / colorization in interactive window" — prior work on content-type/colorization that was prototyped but apparently not fully resolved for theme-adaptive colours.

Suggested customer response

Thank you for reporting this! You've identified a real issue with how the Python Interactive Window renders ANSI console colors on a dark Visual Studio theme. The color values (including "Dark Blue" for keywords and "Black" for some output) are currently hard-coded as absolute RGB values that were designed for a light background — they don't automatically adapt when you switch to a dark theme.

As a workaround, you can override these colors manually: go to Tools → Options → Environment → Fonts and Colors, and in the "Show settings for" list look for entries named "Python Interactive - DarkBlue" and "Python Interactive - Black". Changing their foreground colors to something readable (e.g., a lighter blue or white) will persist across sessions.

We've noted this as a known gap. While we can't commit to a specific timeline, we'll track this as a theme-awareness improvement for the Interactive Window. Thanks again for the detailed report!

Recommended maintainer action: Investigate further — file a spin-off bug to make the ReplOutputClassificationFormatDefinitions theme-adaptive (either by removing hardcoded ForegroundColor for dark-problematic entries and letting VS theme defaults apply, or by supplying per-theme overrides). The customer workaround in the response above is valid in the meantime.

[StellaHuang95]

Triage analysis for AzDO #3009676

Root cause category: PTVS
Confidence: High

Diagnosis

The customer is asking why their VS 2022 Python formatting options page doesn't show the same rich settings (including max line length) as the Microsoft Docs article they linked. This is a legitimate UX gap: the documentation describes an older PTVS experience with a built-in formatter that exposed many per-option controls. The current PTVS formatting options page was redesigned to delegate formatting to external tools (autopep8, black, yapf) and the UI was simplified down to just two settings: formatter selection and "paste removes REPL prompts."

There is no max line length (or other formatter-specific) control in the current PTVS options UI. To configure max line length, users must use the external formatter's own config file: setup.cfg or pyproject.toml for autopep8, pyproject.toml for black, or .style.yapf for yapf. PTVS invokes the formatter as a subprocess, and those tools automatically pick up their config files from the project directory.

The outdated docs page the customer referenced is a documentation gap — it describes a PTVS version with the legacy built-in formatter, not the current external-formatter architecture. The CodeFormattingOptions.cs legacy class still exists in the repo (Python/Product/Common/Parsing/CodeFormattingOptions.cs) but is only used for AST round-tripping, not the editor Format Document command.

Evidence from repo

• Python/Product/PythonTools/PythonTools/Options/PythonFormattingOptions.cs:L1-L71 — Only two persisted settings: Formatter (which external tool to use) and PasteRemovesReplPrompts. No max line length field.
• Python/Product/PythonTools/PythonTools/Options/PythonFormattingOptionsControl.cs:L1-L65 — The options UI only renders a formatter combo box and a paste checkbox; no per-formatter configuration controls.
• Python/Product/PythonTools/PythonTools/Editor/Formatting/PythonFormatterAutopep8.cs:L1-L40 — autopep8 is invoked with --diff and optional --line-range; no max line length argument is passed, so autopep8 falls back to its config file or default (79).

Related issues / PRs

• Black does not support the Format Selection command #8130 — Black does not support the Format Selection command (related formatting limitations with external formatters)
• Format Document not responding. #8125 — Format Document not responding (active formatting bug, shows the current formatter pipeline)

Suggested customer response

Thank you for the report! You're right that the formatting options in Visual Studio have changed. The documentation you linked describes an older version of Python Tools that included a built-in formatter with many configurable options. In newer versions of Visual Studio 2022, formatting is handled by external tools — autopep8, black, or yapf — and VS no longer exposes their individual settings in the Options dialog.

To change the max line length (or other formatter settings), you'll need to configure the formatter directly via its config file in your project folder:

• autopep8: add [pycodestyle] max_line_length = 120 in setup.cfg
• black: add [tool.black] line-length = 120 in pyproject.toml
• yapf: add [style] column_limit = 120 in .style.yapf

We recognize the documentation is outdated and may be confusing — we'll look into getting it updated. Thanks again for taking the time to report this!

Recommended maintainer action: Close as duplicate of #8130 (or close as "by design / workaround available") and file a spin-off bug to update the outdated docs page.

[StellaHuang95]

Triage analysis for AzDO #3018151

Root cause category: Pure Python
Confidence: High

Diagnosis

The user reports being unable to "return a file from my computer to Python" and consistently receiving a "permission is denied" warning. This is almost certainly a standard PermissionError (errno 13) raised by the Python runtime or the Windows OS when attempting to open, read, or write a file path the current user account lacks access to — a common Python beginner issue entirely unrelated to PTVS itself.

No diagnostics log was attached, no repro steps were provided, and no VS/PTVS version info was captured beyond the tags (VS 2019 16.5, Windows 10). The extremely vague description and lack of code context make it impossible to identify any PTVS-specific code path. The ticket was already bulk-closed as stale NMI (no user reply) in May 2020 and then anonymized under GDPR.

There is no evidence of a PTVS bug here. The described symptom is consistent with trying to access a file under a protected directory (e.g., C:\Windows, C:\Program Files) or a file locked by another process — both OS-level restrictions Python surfaces as PermissionError.

Related issues / PRs

None clearly related.

Suggested customer response

Thank you for reaching out! The "permission denied" error you're seeing is a standard Python/Windows message that appears when your script tries to access a file or folder your user account doesn't have permission to read or write.

A few things to try:

1. Check the file path — if you're accessing a file in a protected folder (like C:\Windows\System32 or C:\Program Files), move it to your Documents or Desktop instead.
2. Run as Administrator — if you must access a protected location, try running Visual Studio as Administrator (right-click → "Run as administrator").
3. Check file ownership — right-click the file in Explorer → Properties → Security, and confirm your user account has Read/Write permissions.
4. Ensure the file isn't open elsewhere — if another program has the file locked, Python will also get a permission error.

If none of these help, please share the exact Python code you're running and the full error message, and we'll be happy to take another look!

Recommended maintainer action: Out of scope / not actionable

[StellaHuang95]

PTVS-Triage-Analyze summary

• Posted: 6 new analysis comment(s)
• Skipped (already present from a previous run): 0
• Failed (no analysis file emitted; should not happen): 0

---

Generated by AzDO pipeline PTVS-Triage-Fetch. run details.