How to Fix: ValueError: I/O operation on closed file

This error is a direct result of misunderstanding how the with statement works. The ValueError closed file message typically happens when you try to operate on a file that has already been closed by the context manager.

It means: “You tried to read/write a file, but Python had already closed it.”

# Fix 1 — Do all file work inside the with block
with open("data.txt", "r") as f:
    content = f.read()  # Safe: file is open here
print(content)          # Safe: using the data, not the file object

# Fix 2 — Generator trap: use yield inside with, not return
def stream_logs(filepath):
    with open(filepath, "r") as f:
        for line in f:
            yield line.strip()  # File stays open between yields

# Fix 3 — Pathlib: skip open() entirely for simple reads and writes
from pathlib import Path
content = Path("data.txt").read_text(encoding="utf-8")
Path("output.txt").write_text("New data", encoding="utf-8")

The Cause

The with open(...) as f: block automatically closes the file the moment you un-indent. If you try to use f after that block, the file is gone.

Problem Code:

with open("data.txt", "r") as f:
    content = f.read()
    # The file is open here

# The file AUTOMATICALLY closes here because we un-indented

# CRASH! We try to read 'f' again outside the block
more_content = f.read() 
# ValueError: I/O operation on closed file

The Fix

You must do all your file operations inside the indented block.

Correct Code:

with open("data.txt", "r") as f:
    content = f.read()
    more_content = f.read() # Do it while it's still open!
    
print(content) # You can use the DATA outside, just not the FILE object 'f'.

Common Mistake: Returning the File Object

Never return the file object f from a function if it was opened with with.

# BAD
def get_file():
    with open("data.txt", "r") as f:
        return f # Returns a CLOSED file handle

# GOOD
def get_data():
    with open("data.txt", "r") as f:
        return f.read() # Returns the string content

The “Generator Trap”: Yielding from a Closed File

A more advanced version of this error happens when professionals try to use generators to save memory on large files.

If you return a generator expression from inside a with block, the function finishes, the file closes, and then the caller tries to iterate over the generator. Crash.

The Error:

# BAD: Generator expressions are lazy. 
def stream_logs(filepath):
    with open(filepath, "r") as f:
        # This doesn't read the lines yet. It just creates a generator object.
        return (line.strip() for line in f) 

logs = stream_logs("server.log")
# The 'with' block is now over. File is closed.

print(next(logs)) 
# ValueError: I/O operation on closed file

The Professional Fix: yield directly

Instead of returning a generator object, turn the function itself into a generator by using yield inside the with block. This keeps the context manager active until the generator is completely exhausted.

# GOOD: The file stays open as long as you are yielding values.
def stream_logs_safe(filepath):
    with open(filepath, "r") as f:
        for line in f:
            yield line.strip()

logs = stream_logs_safe("server.log")

# Works perfectly. The context manager pauses at the yield and resumes.
print(next(logs))

Production Alternative: Skip open() Entirely Using Pathlib

If you are just reading an entire file into a string or writing a string directly to a file, managing the with open(...) context is often unnecessary boilerplate.

Modern Python (3.5+) provides pathlib, which handles the opening, reading/writing, and closing automatically in a single, safe C-level call.

from pathlib import Path

# 1. Read entire file safely
content = Path("data.txt").read_text(encoding="utf-8")

# 2. Write entire file safely
Path("output.txt").write_text("New data payload", encoding="utf-8")

Note: Only use read_text() if you know the file size easily fits into your system’s RAM. For massive multi-gigabyte files, stick to the yield generator pattern above.

What This Error Exposes About Python’s Context Manager Protocol

ValueError: I/O operation on closed file is Python’s file object enforcing its post-close state. The with statement implements the context manager protocol — __enter__ opens the file and returns the handle, __exit__ closes it the moment execution leaves the indented block regardless of how that exit happens: normal completion, a return statement, or an unhandled exception. After __exit__ runs, every method on the file object — read(), write(), readline() — checks an internal closed flag and raises ValueError immediately.

The generator trap is the most technically subtle variant. A generator expression inside a with block is lazy — it captures the file object as a reference but reads zero bytes at creation time. The return statement exits the function, which exits the with block, which closes the file. The caller then holds a generator that references a closed file handle, and the crash arrives at the first next() call, far from the function that caused it. Replacing return (line for line in f) with yield line transforms the function into a generator itself — Python suspends execution at each yield, keeping the with block’s stack frame alive and the file open until the caller stops iterating or the loop exhausts the file naturally.

The pathlib alternative eliminates the context manager entirely for simple read and write operations. Path.read_text() and Path.write_text() open, operate, and close the file in a single atomic C-level call — there is no file handle to leak, no indentation boundary to respect, and no closed-file state to hit. For files that fit comfortably in RAM, this is the cleanest pattern in modern Python. For multi-gigabyte files where memory is the constraint, the yield-based generator is the correct architecture — it holds exactly one line in memory at a time and scales to any file size without modification.