Runtime dependency install can upgrade boto3/botocore and break aiobotocore integrations

[patrickvorgers]

The problem

A runtime dependency install appears to be able to upgrade the shared AWS SDK packages globally, leaving Home Assistant with an incompatible aiobotocore / botocore combination.

This breaks integrations using the shared aiobotocore client path, including:

• Cloudflare R2
• IDrive e2

Related issues:

• Cloudflare R2 integration - missing 1 required positional argument: 's3_disable_express_session_auth' #167120
• IDrive e2 integration fails to set up — missing s3_disable_express_session_auth argument #167241

Confirmed broken runtime state

An affected runtime ended up with:

aiobotocore 2.21.1
boto3 1.42.91
botocore 1.42.91
s3transfer 0.16.0

But aiobotocore 2.21.1 requires:
botocore >=1.37.0,<1.37.2

pipdeptree reports:

aiobotocore==2.21.1
 - botocore [required: >=1.37.0,<1.37.2, installed: 1.42.91]

This explains the setup failure:

TypeError: ClientArgsCreator.compute_endpoint_resolver_builtin_defaults()
missing 1 required positional argument: 's3_disable_express_session_auth'

Image vs runtime

The published Home Assistant images I inspected contain the expected compatible AWS package set:

aiobotocore 2.21.1
boto3 1.37.1
botocore 1.37.1
s3transfer 0.11.3

However, docker diff homeassistant on the affected system shows that package files under /usr/local/lib/python3.14/site-packages were changed after container creation. The original boto3, botocore, and s3transfer dist-info directories were removed/replaced, and newer AWS package files were added/changed.

So this does not appear to be caused by the published image itself. It appears to be a runtime dependency install/overlay.

Possible trigger: aioaquacell

aioaquacell==0.2.0 is a strong candidate for introducing the broad AWS dependency upgrade.

Home Assistant pulls it in through:

homeassistant.components.aquacell
→ aioaquacell==0.2.0

aioaquacell==0.2.0 declares broad requirements on:

aiobotocore
boto3
botocore
pycognito

I reproduced the broad dependency upgrade in my HA dev environment by running:

python -m pip install --force-reinstall --upgrade aioaquacell==0.2.0

Before reinstall:

aiobotocore 2.21.1
boto3 1.37.1
botocore 1.37.1
s3transfer 0.11.3

After reinstall:

aiobotocore 3.4.0
boto3 1.42.84
botocore 1.42.84
s3transfer 0.16.0

So aioaquacell==0.2.0 can pull the AWS SDK stack forward.

The affected HA runtime ended up slightly differently:

aiobotocore 2.21.1
boto3 1.42.91
botocore 1.42.91

That suggests boto3 / botocore were upgraded globally, while aiobotocore remained pinned or was restored to the HA-pinned 2.21.1.

Expected behavior

Runtime dependency installation should not leave Home Assistant with an incompatible global AWS SDK package set.

In particular, boto3 / botocore should not be upgraded beyond the version range supported by the installed aiobotocore.

Actual behavior

After runtime package mutation, Home Assistant can end up with:

aiobotocore 2.21.1
botocore 1.42.x

This breaks integrations using aiobotocore, including Cloudflare R2 and IDrive e2.

Possible fix directions

• Constrain aioaquacell / Aquacell requirements so they cannot pull incompatible AWS SDK versions.
• Prevent runtime dependency installs from mutating globally installed packages into a state that violates already-installed Core requirements.

What version of Home Assistant Core has the issue?

core-2026.4.3

What was the last working version of Home Assistant Core?

core-2026.3.3

What type of installation are you running?

Home Assistant OS

Integration causing the issue

core / aquacell

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

So far, reports seem limited to ARM-based systems, but it is not yet clear whether architecture is actually part of the cause or just a coincidence.

[patrickvorgers]

@Jordi1990 , can you also have a look at the aioaquacell integration because of the specified requirements?

[Jordi1990]

@Jordi1990 , can you also have a look at the aioaquacell integration because of the specified requirements?

botocore is also pinned in HA
botocore==1.37.1
with
python -m pip install --force-reinstall --upgrade aioaquacell==0.2.0
you are bypassing HA's requirements_all.txt which pins the versions.

Maybe a custom integration messed with the packages?

[patrickvorgers]

@Jordi1990 , can you also have a look at the aioaquacell integration because of the specified requirements?

botocore is also pinned in HA botocore==1.37.1 with python -m pip install --force-reinstall --upgrade aioaquacell==0.2.0 you are bypassing HA's requirements_all.txt which pins the versions.

Maybe a custom integration messed with the packages?

The strange thing is that something triggered the update of the requirements after the installation and that seems to update the versions similar to what aquacell is expecting as version.

[owine]

I think I've found the actual real-world trigger, and it's not aioaquacell. It's homelink-integration-api==0.0.1, the library required by the built-in gentex_homelink integration.

Its PyPI metadata has Requires-Dist: boto3 with no version constraint. When a user starts the HomeLink config flow in the UI — even if they cancel without finishing — HA pip-installs that requirement, pip re-resolves boto3 to the latest (1.43.4 right now), and botocore gets pulled forward with it.

No --force-reinstall needed. From a clean HA OS install:

1. Settings → Devices & Services → Add Integration → "HomeLink". Start the flow, you don't need an actual device, just cancel out.
2. Restart HA.
3. Cloudflare R2 / IDrive e2 / Nice G.O. fail to set up with the _build_endpoint_resolver TypeError.

That's exactly what happened on my install (HA OS 2026.5.0, ARM64, HA Yellow with CM5). Both homelink-integration-api and pyhive-integration were sitting in site-packages with REQUESTED flags, even though neither gentex_homelink nor hive show up in core.config_entries. Started flows that I never finished.

Diagnostic:

docker exec homeassistant cat /usr/local/lib/python3.14/site-packages/homelink_integration_api-*.dist-info/METADATA | grep ^Requires-Dist
# Requires-Dist: python-decouple>=3.8
# Requires-Dist: boto3              ← no version constraint

pyhive-integration==1.0.9 (used by built-in Hive) has the same problem in a slightly different shape: boto3>=1.16.10 with no upper bound. Should hit any user who has a Hive HomeKit bridge get discovered.

Uninstalling both and restarting HA puts the resolver back in a working state on its own: boto3 1.37.1, botocore 1.37.1, aiobotocore 2.21.1, pip check clean. With those two gone, aiobotocore's botocore<1.37.2 is the tightest constraint, so pip picks compatible versions for everyone else.

Three places this could be fixed:

• homelink-integration-api — add a boto3 upper bound, e.g. boto3>=1.34,<1.38.
• pyhive-integration — same fix.
• HA Core — bump aiobotocore to 3.x once Lift aiobotocore cap IceBotYT/nice-go#790 lands and ships, then bump nice-go in nice_go/manifest.json.

The Core-side fix is the most thorough because it gets HA off the 1.37 botocore line entirely, but the two upstream library fixes are each one line in pyproject.toml and would protect every user regardless of what Core does.

[patrickvorgers]

I think I've found the actual real-world trigger, and it's not aioaquacell. It's homelink-integration-api==0.0.1, the library required by the built-in gentex_homelink integration.

Its PyPI metadata has Requires-Dist: boto3 with no version constraint. When a user starts the HomeLink config flow in the UI — even if they cancel without finishing — HA pip-installs that requirement, pip re-resolves boto3 to the latest (1.43.4 right now), and botocore gets pulled forward with it.

No --force-reinstall needed. From a clean HA OS install:

1. Settings → Devices & Services → Add Integration → "HomeLink". Start the flow, you don't need an actual device, just cancel out.
2. Restart HA.
3. Cloudflare R2 / IDrive e2 / Nice G.O. fail to set up with the _build_endpoint_resolver TypeError.

That's exactly what happened on my install (HA OS 2026.5.0, ARM64, HA Yellow with CM5). Both homelink-integration-api and pyhive-integration were sitting in site-packages with REQUESTED flags, even though neither gentex_homelink nor hive show up in core.config_entries. Started flows that I never finished.

Diagnostic:

docker exec homeassistant cat /usr/local/lib/python3.14/site-packages/homelink_integration_api-*.dist-info/METADATA | grep ^Requires-Dist

Requires-Dist: python-decouple>=3.8

Requires-Dist: boto3 ← no version constraint

pyhive-integration==1.0.9 (used by built-in Hive) has the same problem in a slightly different shape: boto3>=1.16.10 with no upper bound. Should hit any user who has a Hive HomeKit bridge get discovered.

Uninstalling both and restarting HA puts the resolver back in a working state on its own: boto3 1.37.1, botocore 1.37.1, aiobotocore 2.21.1, pip check clean. With those two gone, aiobotocore's botocore<1.37.2 is the tightest constraint, so pip picks compatible versions for everyone else.

Three places this could be fixed:

• homelink-integration-api — add a boto3 upper bound, e.g. boto3>=1.34,<1.38.
• pyhive-integration — same fix.
• HA Core — bump aiobotocore to 3.x once Lift aiobotocore cap IceBotYT/nice-go#790 lands and ships, then bump nice-go in nice_go/manifest.json.

The Core-side fix is the most thorough because it gets HA off the 1.37 botocore line entirely, but the two upstream library fixes are each one line in pyproject.toml and would protect every user regardless of what Core does.

Nice find.
Could you create an issue for the homelink-integration?
I think adding a boto3 upper bound, e.g. boto3>=1.34,<1.38 would be the quick fix.

[owine]

Filed both upstream and opened PRs with the cap:

• Gentex HomeLink: Unpinned boto3 dependency upgrades botocore globally and breaks aiobotocore consumers in Home Assistant Gentex-Corporation/homelink-integration-api#6 / Cap boto3 to <1.38 for aiobotocore compatibility Gentex-Corporation/homelink-integration-api#7
• Pyhive: Unpinned boto3/botocore upgrades break aiobotocore consumers (e.g. Home Assistant) Pyhass/Pyhive#135 / Cap boto3/botocore to <1.38 for aiobotocore compatibility Pyhass/Pyhive#136

Once those merge and release, manifest bumps in gentex_homelink and hive should close both halves of this on the HA side.

[edenhaus]

@owine I think your conclusion is not correct as I tried your steps above but for me the boto3 version will not change. You have probably a custom integration, which requires a newer version that the one installed and so during setup it will be upgraded.
homelink-integration-api is not the issue, even if it has no boto version bounding.

[owine]

@owine I think your conclusion is not correct as I tried your steps above but for me the boto3 version will not change. You have probably a custom integration, which requires a newer version that the one installed and so during setup it will be upgraded. homelink-integration-api is not the issue, even if it has no boto version bounding.

Would the project accept inclusion of the boto packages in package_constraints? That would certainly cover us off in this situation. I am further investigating the transitive dependencies of custom integrations. Best lead so far is pycognito which does not appear to be actively maintained and I am unsure if we will be able to apply an appropriate upper bound there to possible cover this.