I am aware it's "not an error", but it is confusing. Also note how I del both, so they're not just not required, but absent.

I am aware it's "not an error", but it is confusing.

I don't quite understand why this might be confusing.
Schema says that these fields may appear in the result, and that they are not required (may be absent).
This doesn't contradict with the fact that they will always be absent.

Also note how I del both, so they're not just not required, but absent.

Not sure I understand this part.
I meant they are not required according to the schema of ValidationError. That means that response that doesn't contain ctx and input will be valid against this schema.

What can probably be helpful is the ability to disable automatically added 422 response. So that you could disable it and specify it manually as you need.
What do you think?

I personally think in most cases people will not care about these 2 non-required properties being in ValidationError

I’m on that team 🤣 In any case, I’m not sure whether I see this as a middleware approach or as an exception_handler, like this:

@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request, exc):
    errors = [
        {"type": e["type"], "loc": e["loc"], "msg": e["msg"]}
        for e in exc.errors()
    ]
    return JSONResponse(status_code=422, content={"detail": errors})

But I understand your point about having a clean schema

Schema says that these fields may appear in the result, and that they are not required (may be absent).
This doesn't contradict with the fact that they will always be absent.

They are never present in the output of my API. The sheer fact that they are then mentioned in the docs is confusing for my users.

What can probably be helpful is the ability to disable automatically added 422 response. So that you could disable it and specify it manually as you need.
What do you think?

That would indeed provide most flexibility, but being able to customise the ValidationError.errors call (setting include_input=..., include_context=... might be useful as well.