Describe the bug
Importing any Rich submodule fails before application startup when the current working directory exists but os.getcwd() raises PermissionError.
rich/__init__.py captures _IMPORT_CWD at import time and catches only FileNotFoundError. On macOS, getcwd() can raise PermissionError: [Errno 1] Operation not permitted when the responsible application lacks access to the current directory. This breaks unrelated CLIs that import Rich even when the requested operation does not use the cwd.
This is closely related to #2197 and its fix in #2212. That fix handles a deleted cwd, but not other OSError cases.
Minimal deterministic reproducer:
import os
from unittest.mock import patch
with patch.object(
os,
"getcwd",
side_effect=PermissionError(1, "Operation not permitted"),
):
import richActual result:
File "rich/__init__.py", line 17, in <module>
_IMPORT_CWD = os.path.abspath(os.getcwd())
^^^^^^^^^^^
PermissionError: [Errno 1] Operation not permitted
Expected: importing Rich succeeds and _IMPORT_CWD falls back to "", as it already does when getcwd() raises FileNotFoundError.
The real-world trigger was a VS Code integrated terminal on macOS with its cwd inside a Dropbox File Provider directory. The VS Code process lacked macOS access to that directory, so getcwd() returned EPERM; commands using only absolute paths still otherwise worked.
The minimal change appears to be:
try:
_IMPORT_CWD = os.path.abspath(os.getcwd())
except OSError:
_IMPORT_CWD = ""I reproduced the failure with Rich 15.0.0 and current main (9d8f9a372cc5916fd4781fec207ced7ddac2f08f). With the change above, FileNotFoundError, PermissionError (EPERM and EACCES), and a generic OSError all use the fallback. Rich's test suite had the same result before and after the change: 956 passed, 25 skipped.
Platform
- macOS 26.5.2 (25F84), Apple Silicon
- VS Code 1.126.0 integrated terminal
- Python 3.14.5
- Rich 15.0.0 and current
main
python -m rich.diagnose cannot run in the affected state because importing Rich is the operation that fails.
Describe the bug
Importing any Rich submodule fails before application startup when the current working directory exists but
os.getcwd()raisesPermissionError.rich/__init__.pycaptures_IMPORT_CWDat import time and catches onlyFileNotFoundError. On macOS,getcwd()can raisePermissionError: [Errno 1] Operation not permittedwhen the responsible application lacks access to the current directory. This breaks unrelated CLIs that import Rich even when the requested operation does not use the cwd.This is closely related to #2197 and its fix in #2212. That fix handles a deleted cwd, but not other
OSErrorcases.Minimal deterministic reproducer:
Actual result:
Expected: importing Rich succeeds and
_IMPORT_CWDfalls back to"", as it already does whengetcwd()raisesFileNotFoundError.The real-world trigger was a VS Code integrated terminal on macOS with its cwd inside a Dropbox File Provider directory. The VS Code process lacked macOS access to that directory, so
getcwd()returnedEPERM; commands using only absolute paths still otherwise worked.The minimal change appears to be:
I reproduced the failure with Rich 15.0.0 and current
main(9d8f9a372cc5916fd4781fec207ced7ddac2f08f). With the change above,FileNotFoundError,PermissionError(EPERMandEACCES), and a genericOSErrorall use the fallback. Rich's test suite had the same result before and after the change: 956 passed, 25 skipped.Platform
mainpython -m rich.diagnosecannot run in the affected state because importing Rich is the operation that fails.