been having issues with python processing on gpt 5.5
documented below.
Issue: Validation, inspection, packaging, upload, indexing, publication, and artifact workflows can fail when hidden helpers or bare Python commands are treated as trustworthy evidence. Platform tools may silently invoke metadata scanners, artifact helpers, or indexing logic through unknown paths, sometimes using bare `python` / `python3`. These paths can hang, fail silently, inspect generated files unexpectedly, or contaminate results through virtualenv hooks, `.pth` files, `sitecustomize.py`, user-site imports, or platform wrappers. Retrying the same failing path hides the true failure layer and can make the workflow unstable.
Fix: Trust only evidence from visible, reproducible, bounded, and logged execution. Use filesystem-level commands with explicit executable paths, clean environments, and timeouts. For isolated Python, prefer `env -i PATH=/usr/bin:/bin PYTHONPATH=. /usr/bin/python3 -S ...`. Record command, working directory, inputs, outputs, stdout, stderr, exit code, duration, timeout behavior, retries, and reroutes. If a command hangs, fails, or exits ambiguously, stop and switch to a materially different path. Avoid many per-test stdout/stderr files; hidden metadata scanners may inspect each one and trigger secondary hangs. Prefer consolidated logs. Verify artifact creation, checksum, archive integrity, upload, publication, and indexing as separate lifecycle stages. If any stage cannot be independently verified, report partial validation instead of full success.
My current work around is a preamble i apply to each project included below.
Validation, inspection, packaging, publication, upload/indexing, and artifact-handling workflows must use reproducible filesystem-level commands whenever possible.
Do not rely on notebook-state, hidden internal Python execution, platform metadata helpers, artifact-helper side effects, connector-side indexing, or bare `python` / `python3` helper commands as the primary validation, inspection, metadata, packaging, checksum, archive, upload/indexing, publication, or artifact lifecycle path.
A tool result is not automatically validation evidence. Treat tool results as convenience output unless the execution boundary is visible, reproducible, bounded, and logged.
Any command used for validation, inspection, metadata scanning, package assembly, checksum generation, archive validation, upload/indexing, artifact publication, connector handoff, or artifact lifecycle handling must record:
- executable path
- interpreter path, when applicable
- interpreter startup mode, when applicable
- full command
- working directory
- relevant environment variables
- input files and paths
- output files and paths
- stdout
- stderr
- exit code
- duration
- timeout/deadline behavior
- retry behavior, if any
- fallback/reroute behavior, if any
- required manual cleanup, if any
Every validation, inspection, packaging, publication, upload/indexing, connector handoff, and artifact lifecycle command must run under an explicit bounded timeout or deadline. Timeout exit behavior must be logged as a first-class validation result.
When Python isolation is required, prefer:
env -i PATH=/usr/bin:/bin PYTHONPATH=. /usr/bin/python3 -S ...
This avoids virtualenv/site startup hooks, `.pth` import hooks, `sitecustomize.py`, user-site imports, and platform wrapper side effects.
Do not use `python -s` as a default workaround. Use it only when testing user-site import effects. It is not sufficient for bypassing virtualenv site-packages, `.pth` execution, `sitecustomize.py`, platform artifact-tool startup hooks, or unknown helper wrappers.
If an inspection, validation, packaging, publication, upload/indexing, connector handoff, or artifact-handling command fails, hangs, times out, exits ambiguously, produces incomplete output, or appears to succeed without observable evidence, stop repeating the same failing path. Capture the exact command, stdout, stderr, exit behavior, timeout behavior, duration, partial outputs, and cleanup needs. Then choose a materially different explicit command-line approach.
If a tool or helper performs hidden metadata inspection, artifact scanning, package assembly, upload/indexing, publication, connector transfer, file discovery, semantic indexing, or artifact lifecycle handling through an unknown execution path, treat the result as untrusted unless its command path, startup behavior, timeout behavior, stdout/stderr, exit code, duration, and output provenance are observable.
Platform tools, connectors, upload handlers, file indexers, artifact publishers, semantic retrieval systems, and hidden metadata scanners may fail, stall, omit files, return stale results, produce partial results, or inspect generated artifacts through unknown bare-Python paths. Their output must not be treated as authoritative validation evidence unless independently confirmed through reproducible filesystem-level inspection or another auditable source.
Do not create large numbers of per-test stdout/stderr artifact files unless the artifact lifecycle path itself is under test. Platform artifact scanners may inspect each generated file through hidden bare-Python paths, causing secondary hangs unrelated to the command being tested.
When testing validation or inspection rules, prefer consolidated log files over many per-command output files. If per-command files are required, treat platform metadata inspection of those files as a separate artifact-lifecycle risk surface.
When a platform tool or connector fails, do not assume the target artifact, file, repository, message, or external resource is invalid. First classify the failure layer:
- user input or path error
- local filesystem error
- interpreter startup error
- command execution error
- package/archive format error
- metadata scanning error
- upload/indexing error
- connector/API error
- platform/tool session error
- external service error
- hidden artifact scanner error
For each failure, record what was observed and what remains unknown. Do not collapse distinct layers into one root cause without evidence.
When file indexing, semantic search, or connector retrieval is involved, retrieved results must include enough provenance to be trusted:
- source name
- file or resource identity
- path or stable reference
- version or timestamp, when available
- matched content or cited lines, when available
- retrieval query or selection method
- limitations or missing evidence
If retrieval evidence is incomplete, stale, or inconsistent, mark it provisional and use direct file inspection, explicit search commands, or connector-native reads where available.
Artifact upload, publication, and indexing success must be verified separately from artifact creation. Local file existence does not prove upload or indexing. Upload success does not prove correct indexing. Index success does not prove artifact integrity.
For generated artifacts, verify each lifecycle stage independently:
- source artifact exists
- file size is nonzero and plausible
- format signature is valid
- archive/container opens successfully
- expected files are present
- checksum is generated
- publication/upload completes
- returned artifact link or identifier exists
- indexed/discoverable artifact matches expected checksum or metadata when possible
If any lifecycle stage cannot be verified, report the artifact as partially verified rather than fully validated.
Retries must be bounded and purposeful. Do not repeatedly invoke the same failing command, helper, connector, upload path, indexing path, publication path, or metadata scanning path. A retry is valid only if at least one material condition changes, such as executable path, interpreter startup mode, environment, timeout, inspection command, artifact path, connector method, direct filesystem inspection, direct API/resource read, or consolidated logging.
When a tool session crashes, closes, hangs, times out, or returns no usable result, record the failure as a tool/session failure. Do not infer success or failure of the target task from a missing, stalled, or unusable tool response.
If a timeout test, sleep probe, or deliberately hanging command causes the surrounding tool session to hang, classify it as a tool-session failure unless command-level timeout evidence is captured. Do not repeat the same timeout probe unchanged.
When a tool cannot show how it executed, it cannot be trusted as validation evidence.
A validation result is trustworthy only when the command path is reproducible; executable and interpreter paths are explicit where applicable; interpreter startup behavior is known; environment influence is bounded or recorded; stdout/stderr, exit behavior, duration, and timeout behavior are captured; outputs are independently inspected; upload/indexing/publication stages are separately verified; connector or platform results are provisional unless independently confirmed; generated test artifacts do not trigger unbounded hidden metadata scanning; deliberately hanging probes do not destabilize the surrounding tool session or are reported as blocked; and surrounding artifact lifecycle steps can complete without hidden bare-Python metadata-helper hangs.