This rule raises an issue when a file permission mode is passed as a non-octal integer literal to APIs such as os.chmod.

Why is this an issue?

Unix-style permission modes are conventionally written as octal values, for example 0o755 or 0o644. Those digits describe user, group, and other permissions in base 8.

When the same digits are written without the 0o prefix, Python treats them as decimal. The resulting mode is therefore not the permission set the author usually intends.

For example, os.chmod(path, 755) applies decimal 755, which is octal 0o1363, not the common executable mode 0o755. Similarly, 644 is not 0o644.

This is a frequent footgun for developers coming from shell chmod 755 file usage, where 755 is interpreted as octal.

The same risk applies to other standard-library calls that take a numeric mode, including os.fchmod, os.lchmod, os.mkdir, os.makedirs, os.open, os.umask, and pathlib.Path methods such as chmod, mkdir, and touch.

What is the potential impact?

How to fix it

Write permission modes as octal literals with the 0o prefix so the value matches the intended Unix mode.

The literal 0 is clear on its own and does not need an octal prefix.

Intentional decimal mode literals are rare. Treat them as won’t-fix only after review confirms the decimal value is deliberate rather than a mistaken shell-style octal.

Code examples

Noncompliant code example

import os

os.chmod("file.txt", 755)  # Noncompliant

Compliant solution

import os

os.chmod("file.txt", 0o755)

Noncompliant code example

from pathlib import Path

Path("config.ini").chmod(644)  # Noncompliant

Compliant solution

from pathlib import Path

Path("config.ini").chmod(0o644)

Resources

Documentation

External coding guidelines