# ShadowedDcode

> **Class** in `deepagents_code`

📖 [View in docs](https://reference.langchain.com/python/deepagents-code/update_check/ShadowedDcode)

A different dcode entry point is winning on PATH than the one we upgraded.

Returned by `detect_shadowed_dcode` after a successful upgrade so the TUI can
warn the user that re-launching will pick up the wrong binary. The most
common cause is a pre-uv install (e.g. a leftover from a previous
`pipx`/`pip`-based install) earlier on `PATH` than the uv tool shims.

A frozen dataclass rather than a `NamedTuple` (unlike the sibling
`DependencyChange`) so `__post_init__` can enforce the conflict invariant
the type's name promises: an instance only exists when there genuinely is
a shadow. The producer already guarantees this, so the check is defensive
against future direct construction, not a runtime gate on the hot path.

## Signature

```python
ShadowedDcode(
    self,
    shadowing_bin: Path,
    upgraded_bin_dir: Path,
)
```

## Constructors

```python
__init__(
    self,
    shadowing_bin: Path,
    upgraded_bin_dir: Path,
) -> None
```

| Name | Type |
|------|------|
| `shadowing_bin` | `Path` |
| `upgraded_bin_dir` | `Path` |


## Properties

- `shadowing_bin`
- `upgraded_bin_dir`
- `upgraded_bin`

---

[View source on GitHub](https://github.com/langchain-ai/deepagents/blob/e14e0adcbe78565ed3650e7f24b2a775d5437d25/libs/code/deepagents_code/update_check.py#L1410)