We’re doing a live stream today on the CritterWatch 1.0 release — but it’s maybe a little dicy whether the official release happens before or after the live stream:-)

PowerToys v0.101.2312.0 Preview

This preview release fixes Shortcut Guide activation, preserves transparency in SVG thumbnails, prevents a Screen Ruler settings crash, and updates Window Hopper discovery.

Installer Hashes

Description	Filename	sha256 hash
Per user - x64	PowerToysUserSetup-0.101.2312.0-x64.exe	0CE7DC41F2CA13C93AFFAAE50CD4B681442D9FFC082078B8DA6EC14246157AC1
Per user - ARM64	PowerToysUserSetup-0.101.2312.0-arm64.exe	5664F4582AFFDE22615A67BD96C4FE2E1C4F88D58E92BC3E2B19F006A0A54B90
Machine wide - x64	PowerToysSetup-0.101.2312.0-x64.exe	B0289AD15A29B6E2AC4DAC885ED1AB5311578F2BA1984BACDA319A0109C5F8E7
Machine wide - ARM64	PowerToysSetup-0.101.2312.0-arm64.exe	89E5842A1C2515D6811589FD0B5032C6DFA4555FF56772E3CB5A9A466268D04E

Highlights

• Shortcut Guide: Made Win+Shift+/ reliably open the full guide independently of Windows-key hold settings and remain visible after Win is released.
• File Explorer: Preserved transparent backgrounds in SVG thumbnails instead of rendering them black.
• Screen Ruler: Migrated legacy measurement-unit settings to prevent Settings from crashing when leaving the Screen Ruler page.
• Window Hopper: Moved the New badges from Shortcut Guide to Window Hopper across Settings and the welcome experience.

Advanced Paste

• Added regression coverage to keep custom actions compatible with OpenAI models that do not support reasoning-effort settings in #49867 by @Sthitadhi1.

File Explorer

• Preserved transparent SVG thumbnail backgrounds and fixed an image-resize resource leak in #49301 by @pedrolamas.

PowerToys Run

• Added PoetSearch to the third-party plugin list for searching classical Chinese poetry in #49946 by @Greyaircraft.

Screen Ruler

• Migrated legacy measurement-unit values to valid settings, preventing Settings from crashing when navigating away from Screen Ruler in #49898.

Shortcut Guide

• Separated regular-hotkey activation from Windows-key hold activation, so Win+Shift+/ reliably opens the full guide and stays visible after Win is released in #50000 by @LegendaryBlair.

Window Hopper

• Moved the New badges from Shortcut Guide to Window Hopper throughout Settings and the welcome experience in #49995.

Development

• Separated common .NET project properties from WinRT-specific settings and made CI validation faster and more robust in #48059 by @daverayment.

Framework has refreshed its 12-inch convertible laptop, introducing Intel's latest Core Series 3 processors, expanded hardware customizations, and a pre-built Linux option. The cheapest pre-built base configuration for the Framework Laptop 12 now starts at $699 - $100 less than the previous version when it launched last year. Preorders are open now, with the first wave of deliveries expected to ship in October.

That pre-built base configuration is only available in green, and includes an Intel Core 3 304 CPU, 8GB of RAM, and 512GB of storage. It also comes preloaded with Linux Fedora 44 KDE Plasma, a decision brought on by Framework finding …

Read the full story at The Verge.

Visual Studio 2026 version 18.9 adds Copilot thinking effort controls, a Git review agent and org-level custom agents, followed by an August 18 bug-fix update.

Across the PyCharm 2026.2 release line, we shipped 263 fixes and improvements. Many improve Python code insight directly, with more precise type inference, fewer false positives, smarter completion and imports, and more reliable refactoring. Here are some of the smaller changes you’re likely to notice in everyday Python development.

---

SQLAlchemy 2.0 support

SQLAlchemy has been a long-standing source of false positives – enough that several duplicate tickets have accumulated over the years. This release resolves a batch of them for the 2.0 style.

String forward-references inside Mapped[...] resolve correctly:

posts: Mapped[list["Post"]] = relationship(back_populates="author")

# "Post" now resolves to the model class

PyCharm also correctly infers the mapped type returned by Session.get(), instead of treating the result as the model class itself:

report = session.get(Report, report_id)

reveal_type(report)  # was: type[Report] | None   now: Report | None

Modern hybrid_property setters written as @name.inplace.setter are recognized, so assigning to the property no longer produces a warning. Model class attributes defined via mixins are picked up again, too, clearing the old unexpected argument reports on model constructors.

(PY-78816, PY-65142, PY-59732, PY-51906, PY-28762)

---

Code insight and type inference

Control-flow narrowing and “unreachable code”

Several false This code is unreachable reports and instances of lost narrowing across loops have been fixed. The common issue: flow analysis either gave up or over-eagerly narrowed to Never in branches it should have kept alive.

isinstance on a numeric union no longer kills the else branch:

def foo(y: int | float) -> None:

    if isinstance(y, float):

        pass

    else:

        print(y)  # was flagged unreachable, y inferred as Never

Narrowing also survives a while loop, so re-narrowing an optional attribute inside the loop body no longer reports a bogus has no attribute error.

(PY-83206, PY-83354, PY-88265)

Strings inside type annotations

A string used as metadata inside Annotated[...] – a Pydantic discriminator field name, for instance – is no longer parsed as a forward reference and flagged as unresolved.

(PY-48749, PY-82245)

Iterable unpacking and star expressions

PyCharm’s analysis of tuple and star unpacking could lose type information and fall back to Any. Unpacking a starred value into a tuple lost its element types, *-expansion collapsed to Any, and several genuine errors went unreported. Starred expressions preserve their element types:

def a() -> tuple[int, int]:

    return 2, 3

def b() -> tuple[int, int, int]:

    return (1, *a())  # no more bogus "Expected tuple[int, int, int]"

(PY-12592, PY-27205, PY-43585, PY-90219)

Augmented assignment

A cluster of false positives came from augmented assignments being misanalyzed. A simple /= on an int produced the wrong type:

foo = 5

foo /= 2

reveal_type(foo)  # was: int   now: float | int

(PY-80622)

Self and constructor return types

Self binds correctly through classmethod parameters typed as type[Self]:

class A:

    @classmethod

    def bar(cls, y: type[Self]) -> Self: ...

x = A.bar(A)      # was a spurious "Expected type[A], got type[A]"

reveal_type(x)    # was: Any   now: A

Construction also respects __new__, __init__, and metaclass __call__. When __new__ returns something other than an instance, that’s the constructed type – even when an __init__ is present. The same fix covers explicitly parameterized calls like MyClass[int]() and __new__ assigned as a class attribute.

(PY-89296, PY-77611, PY-88644, PY-89571)

Enum members: Literal types for .value and .name

Reading an enum member’s .value or .name yields a precise Literal instead of a widened str or int, so assignments to Literal[...] target type-check. This matches mypy’s inference:

from enum import Enum

from typing import Literal

class E(Enum):

    a = "a"

b: Literal["a"] = E.a.value   # was: Expected 'Literal["a"]', got 'str'

n: Literal["a"] = E.a.name    # .name is a Literal too

(PY-61028, PY-79198)

Parameter types inferred from decorators

When a decorator constrains the callable it accepts, the decorated function’s parameters are inferred from that constraint instead of falling back to Any:

from typing import Callable

def d(fn: Callable[[int], str]): ...

@d

def f(a):

    reveal_type(a)   # was: Any   now: int

(PY-79204)

Also fixed

• Keyword arguments in a class header are validated against the base class’s __init_subclass__ signature, and offered in completion (PY-79173).
• An ellipsis in a Callable used as a PEP 695 type-parameter bound no longer reports a bogus Invalid type expression (PY-83570).
• Type-checker findings are split into granular suppression codes rather than a single PyTypeChecker id, and # noinspection directives accept a simplified name form. PyTypeChecker still works as a blanket ignore (PY-90265).

---

Completion and auto-import

Smarter auto-import 

Auto-import is now noticeably less noisy. Previously, if a module was already imported, PyCharm would offer to add a second, redundant import instead of qualifying through the one you already had. The quick-fix – and the completion popup – prefer to reuse the existing import.

Given pkg/src.py containing MyClass, and a file that already imports the module, Alt+Enter produces this:

from pkg import src  # no longer flagged as unused

src.MyClass

instead of adding from pkg.src import MyClass. The same reuse logic applies to plain import pkg.src, and to the auto-import completion on a second Ctrl+Space.

Nested classes can be auto-imported too, which is something PyCharm didn’t previously support:

# mod.py

class Outer:

    class Inner:

        pass

# main.py – Alt+Enter on Inner now offers "Import Outer from mod"

from mod import Outer

value = Outer.Inner()

(PY-87970, PY-87971, PY-87972, PY-88009, PY-88016)

Completion for unittest.mock.patch() targets

Patching by string target previously offered no code assistance, so dotted paths had to be entered manually. The string argument to mock.patch(...) gets code completion for modules, classes, and their attributes, and it no longer suggests the invalid as keyword mid-path:

from unittest import mock

# sample.py defines: class Foo: my_attr = 42

with mock.patch("sample.Foo.my_attr", 14):

    ...

# completion now offers `sample`, `Foo`, and `my_attr`

(PY-89189, PY-89191, PY-89192)

Typed signatures when overriding built-in methods

Completing an override of a dunder or built-in method fills in the full annotated signature – and auto-imports the types it needs – instead of bare parameters:

from types import TracebackType

class A:

    def __exit__(self, exc_type: type[BaseException] | None,

                 exc_val: BaseException | None,

                 exc_tb: TracebackType | None): ...

# was: def __exit__(self, exc_type, exc_val, exc_tb):

(PY-79218)

---

Editor and inspections

Type inlay hints

Inferred type arguments are shown inline at the call site, so you can see what a generic resolved to without hovering over it:

class A[T]:

    def __init__(self, t: T): ...

A[int](1)     # [int] shown as an inlay hint

Type names rendered inside inlay hints – return types and solved arguments alike – are also clickable, so you can jump straight to a type’s definition from the hint.

(PY-90411, PY-90293)

f-string format-spec validation

PyCharm already validated the str.format() mini-language. Those checks apply to f-strings too, and PyCharm flags formatting a type that doesn’t implement __format__:

data = 1

f"{data:.2f}"   # ok

f"{data:.2q}"   # now flagged: unsupported format spec

class A: ...

f"{A():d}"      # now flagged: A doesn't support the 'd' format

(PY-51322, PY-89760)

---

Refactoring

The Rename refactoring also updates references to a module when the module itself is renamed. Previously, the renaming left importing sites pointing at the old name:

# rename provider/provider_module.py → some_module.py

from ..provider import provider_module  # this reference is updated too

(PY-53274)

The Refactor | Field action is now Attribute, and the documentation says “instance attributes” to match Python terminology (PY-85828).

---

Conclusion

Taken together, these changes make PyCharm’s understanding of Python more precise and predictable: fewer false positives, better type inference, smarter completion, and less time spent working around cases where the IDE gets valid code wrong.

Many of these improvements started with real-world examples reported by users. If PyCharm still misunderstands a typing pattern, framework API, or other valid Python code in your project, let us know in YouTrack – a small reproducer can help us turn that friction into the next fix.

Try PyCharm 2026.2 and let us know which improvements make the biggest difference for your workflow.

Thank you for using PyCharm!

The latest round of restrictions and safeguards for frontier models are overly fussy and limiting. A Claude skill that I created demonstrates what happens when guardrails go astray. My skill helps me to find articles and blog posts that go into O’Reilly Radar’s monthly Trends to Watch. It reads roughly a dozen well-known sites like The New Stack, The Next Web, and Hacker News, plus any other sources that it finds useful. After reading the sites, it produces a digest of the most important articles published in the last day. I use it as a sanity check on my own reading: Did I miss anything important? Am I on the fence about something that might be an important leading indicator?

I’ve used the skill daily for a couple of months now. It suddenly stopped working with the following message:

API Error: Sonnet 5’s safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate cybersecurity work. Apply to the Cyber Verification Program to reduce these interruptions. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude

When I started a new Claude Code session with Haiku, the skill worked without problems. (I didn’t try Opus or Fable; if Sonnet found the skill dangerous, I’m sure Opus and Fable would draw the same conclusion.) GPT 5.6 with “high” reasoning was able to execute a very similar skill without problems. So what happened to Sonnet?

The best approach to debugging AI is often to ask the AI itself, so I pasted the message into another Claude Code session and asked it what was happening. The response came down to the descriptions of Hacker News, Bleeping Computer, and The Register. The phrase “vulnerabilities, exploits, threat reporting” in the description of Hacker News triggered Sonnet’s guardrails. Ironically, that description is both incorrect and Claude generated. (Reminder to self: Be more careful when asking Claude to develop a skill from a task.) Sonnet came up with three solutions, the first of which was to let it rewrite the skill with more neutral descriptions like “security industry news.” Fair enough, but I did the editing myself.

Then I went back to the original Claude Code session. It still didn’t work. I expected that I’d need to do something to reload the skill, but the problem was worse. Regardless of the prompt, the original session wouldn’t do anything except repeat the error message. It wouldn’t even commit the modified skill to my GitHub repo. However, Sonnet executed my skill correctly in a new Claude Code instance.

So I returned to Sonnet to find out what’s going on. The answer was interesting: The error may have been triggered by the skill, but when evaluating security threats, the models base their decisions on the entire conversation, not just the specific skill that was called. If a model needs to call a skill that it thinks is problematic, that call is part of the conversation, part of the context. The entire conversation is then forever dead and lost.

What can we learn from this? First, it’s a problem for a program to stop working because of a change over which you have no control. If anything, the industry has erred on the other side; we’re all familiar with “we don’t really understand why this works, so don’t touch it, don’t update the compiler, don’t update the libraries, and run it on emulators of computers that haven’t been built in 40 years.” That’s not just a problem for COBOL code from the 1970s; we see the same thing with C, C++, Java, JavaScript, and just about every language that ever went into production. Legacy code is everywhere. The “don’t change anything” approach isn’t necessarily a bad thing; it certainly beats “here’s a new library, you’re going to love it, you can’t use the old version any more, and wow, look at all the things it broke, guess you’ll have to fix them.” AI where working code breaks at random is a lot less useful than AI that works day in and day out. Stability is a virtue. It’s impossible to work effectively when the environment changes from day to day and isn’t under your control.

But that’s not really what bothers me. It’s rather bizarre that reading well-known sources is treated as a security risk, especially when the “risk” seems to come from an AI-generated description. Of course, we know about hallucinations, errors, and prompt injections. The possibility of a Hacker News post that injects a hostile prompt isn’t zero, and it’s also possible that a model might mistakenly interpret an example of a hostile action as a prompt. I also don’t expect any model to reason that a skill must be safe because it’s been in use for months (though files have time stamps). Artificial intelligence always coexists with artificial stupidity, as does natural intelligence.

Guardrails may keep you from going off a cliff, but they may also prevent you from going where you need to go. And that’s a problem. There’s a basic concept from signal processing and data science called the receiver operating characteristic (ROC). In any binary classification system, you can never achieve perfect classification. The only way to guarantee that no true positives (dangerous things) slip through the classifier is to reject everything. The opposite is equally true: The only way to eliminate false positives (things that look dangerous but aren’t) is to let everything through, including dangerous actions. In theory, it’s possible to get arbitrarily close to perfect classification, but you know how that goes: “The difference between theory and practice is bigger in practice than in theory.”

We know how to make AI “safe”: Go back to 2022 and models that can only tell the difference between cats and dogs. The model might mislabel a few things, but the consequences of an error are small. Safety comes with limitations, and none of us who use AI for real work want to return to the days of dogs, cats, and bananas. And while I don’t want the ability to use Claude to generate hostile attacks against unsuspecting victims, and while I understand the danger of interpreting any input text as a command (for example, an article describing the Morris worm), I have a problem with an AI that refuses to perform reasonable tasks. The ROC tells us that we can’t have perfect guardrails, but there’s no rule against overly fussy ones. What’s allowed, and what’s forbidden? What are the limits? We don’t know. And that’s the situation we’re in now. We can’t know in advance what is and isn’t acceptable, and the rules can change at any time. A tool with unknown limitations is much less useful than a tool that tells you what it can and can’t do. I’ve enjoyed using Claude to write programs that play with prime numbers and infinite series, and fortunately I don’t rely on any of those programs for my job. But what if tomorrow (or a month from now or a year from now) Claude decides that testing whether large numbers are prime signals an attack against cryptography?

I’m not completely unsympathetic to scoring an entire conversation rather than individual actions. A series of steps, each of which appears innocuous by itself, is more likely to lead an agent to a hostile action than a single prompt. But again, given how valuable context is, do we really want the penalty to be losing all the context for an innocuous project? There are risks on either side, including the possibility that a model will ignore its guardrails; after all, rules that a harness adds to the context are at best advisory.

Guardrails always have unintended consequences. We need to learn what the ROC is teaching us: that it’s impossible to get to the upper left corner of the diagram, where we have perfect rejection of true positives (dangers) and no rejection of false positives. But we also need to get as close to that upper left corner as possible if we want our classifiers to have consistently useful output. An engineering team needs to balance risk against usefulness, and they’re clearly out of balance now. Risks will never go away, but guardrails whose boundaries are unclear and overly strict lead to models and agents that are less useful, rather than more. The bad guys will always figure out how to do bad stuff. Hamstrung AI for the rest of us is not a solution.