Limitations and security

Use tuiify with supported synchronous functions and understand which inputs and execution patterns require another approach.

Use supported function signatures

Build forms from regular synchronous functions whose visible parameters use these annotations:

str
int
float
bool
typing.Literal[...]

Call the decorated function with no arguments to open the form. When you pass arguments, tuiify calls the original function directly instead.

Avoid unsupported patterns

Do not rely on tuiify to convert these annotations or signature features:

Pattern	Behavior
`Optional`, `Enum`, `Path`, date types, lists, dataclasses, custom classes, or unannotated parameters	tuiify does not explicitly support them; values may be submitted as text rather than the type your function expects.
Positional-only parameters	Submission fails because tuiify calls the function with keyword arguments.
`async def` functions	tuiify calls functions synchronously and does not await coroutine results.
`args` and `*kwargs`	tuiify omits variadic parameters from the form.

Use a wrapper function with supported parameters if you need to call more complex application logic. Validate domain-specific constraints inside that function and raise a clear exception; tuiify shows the resulting traceback in the form.

Treat functions as trusted code

Only decorate functions you trust. tuiify's form invokes the supplied Python function with user-provided form values, so the function and the environment where it runs are part of your security boundary.

Do not use a tuiify form as a sandbox for arbitrary code. Review input handling, file access, credentials, and other side effects in the decorated function before distributing the script.

Report a security issue

Report potential vulnerabilities through the repository's GitHub private security advisories rather than a public issue. Visit the tuiify repository to submit a report.