Documentation

This large block of commented-out code should be deleted to reduce clutter:

#needs some fix, de-comment this to see.
'''
for idx, char in enumerate(senha): #this is the code i need help. look at the '#string scrambler' to see an better code than this here with same objective.
    for step in range(len(lista[3])):
        if lista[5][step] == 1:
            continue

Alternate versions of code can be stored in you version control system during development.

there is no need for long lines inside a docstring:

This function creates an list (like string) with some caracters of the password, then a code to the password with the list made, which is allways the same for the same password.\n

That line should be shortened by splitting it up into multiple lines.

Many of the lines in the doctring end in literal \n characters which can be deleted:

Then checks to the mode:\n

Simpler

This line:

if debug == True:

is simpler as:

if debug:

This line:

print(f"Password was really wrong.")

is simpler without the f-string:

print("Password was really wrong.")

ruff identifies other similar issues.

Naming

The PEP 8 style guide recommends snake_case for function and variable names.

The function name coddecod is strange. Perhaps code_decode is more meaningful.

The variable reallywrongpassword would be really_wrong_password.

senha does not convey much meaning in English. Either choose a more descriptive name or add a comment to describe what it means. The same is true for other variables like lista, etc.

illegible source code

You may think that future maintainers of this code will be glad to read lines longer than 180 characters long. Perhaps there are some humans who fit that description. But you are needlessly limiting the scope of future team mates. Write code so people can read it. If you've gone much past 100 characters per line, then it's time to rethink things.

triple quote

print(f"The text is: 'Elias'.\nThis is the message ...

Ok, that's just silly, when we go much more than two hundred characters beyond the left margin. Python has perfectly good facilities for representing such a sequence of codepoints while keeping them legible. Prefer

print(f"""The text is: 'Elias'.
This is the message ... """)

design of Public API

Naming a function "code de-code", and accepting a mode flag, is probably a mistake. At a minimum it prevents type checkers like mypy from verifying that caller used the proper types for the intended mode.

Prefer to present a pair of functions in your Public API, without a modo flag.

respect the signature order

You supplied a docstring. Thank you.

def coddecod (senha: str, texto: str | list, modo = 'd', debug = False) -> list|str:
    '''String <=> List\n|
    debug (True / False) is an option that show more information about the process if marked as True\n
    texto (String / List) is the text to be Encrypted or Decrypted.\n
    modo ( 'c' / 'd' ) is how the function will be used, it can be 'c' (Encrypt) or 'd' (Decrypt).\n
    senha (String) is the password to be used to Encrypt/Decrypt (Needs to be the same on both sides).\n

What are all those \n newlines doing in there? Ok, fine, we'll just ignore them.

Rather than offer explanations in the order
{debug, texto, modo, senha}, please prefer the signature order of
{senha, texto, modo, debug}. It's just how the human brain works. Maintainers anticipate seeing such things appear in the same order with parallel construction, so a consistent narrative will evolve. Scrambling the order gratuitously throws a monkey wrench into that for no gain.

typo

For "caracters", read "characters". Yes, I understand the Portuguese word "caracteres" lacks "h". It's worth getting used to, if only to make sense of common abbreviations like "char" and "ch".

Also, after "Then checks to the mode" I failed to glean much of use. The signature already told me that we're going to encode and decode. But as far as the details go, all the docstring really told me was that I'd have to read the source to tell exactly what happens.

keying material

If you call it senha or contrasena or mot_de_passe or wachtwoord; I don't much care.

What does concern me is that you've not written down any assumptions about how many bits of entropy it should contain. As written it appears the Concept of Operations is for a person to type an "easily remembered" password or passphrase, which likely has fairly low entropy.

The whole point of crypto is to make it "hard" for Eve to recover the plaintext, and here you're not giving any hints about what "hard" means. Must she do \$2^{256}\$ work? Must she do "trivial" work, as for rot13?

During a Code Review we answer these questions:

1. Does it work?
2. Is it maintainable?

We can't really address whether it "works" well if we can't tell what Security Parameter (256 bits?) you're shooting for, and whether there's reason to believe the implemented code matches that spec. You need to be explicit about your security objectives.

boolean variable is a boolean expression

    if debug == True:

No.

Please just write if debug:

magic constant

    lista = ["0bm1!d2Mafgh3TtijkcheH4lnEou5pqUsr67Svwx8yz9BCDFGHIJ...

That's crazy. Why start with "0bm1" and not "1m0b" or another permutation?

Recall Kerckhoffs's principle. Eve has already read your source code. The details of lista are already known to her.

Much better to lexically sort the valid characters in the source code, and then permute them:

    lista = [" !!#$%&()*+-0123456789=@BCDEFGHHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghhijklmnopqrstuvwxyz|~ª°º", ...

Uggh, wait! Why do we have a pair of ! bangs in there? And a pair of capital H's? Also a pair of lowercase h's?!?

... makes an string with 85 ...

No, after dups it looks more like 84 distinct codepoints, to me.

BTW, kudos on using _ in for _ in range(5): to say that we won't use and don't care about the index value -- no need to name it.

more magic numbers

        lista[3].append( ... )

This is not great. The 3 is cryptic. Prefer to use a dict or @dataclass for a mutable structured tuple such as this.

tl;dr: Name your fields!

        step += 17

I imagine we might have a Caesar cipher going on here? It's obscure. Cite your references.

Also, you wrote some commented code. It doesn't execute; I didn't read it. Present working code on the Code Review site, and buggy code over on Stack Overflow.

another magic constant

    for idx, char in enumerate("0" + senha):

I can't imagine why we're prepending "0" there. It warrants a # comment.

If you write mysterious code, don't be surprised if a future teammate / maintainer rips it out because it's unclear it's doing anything useful.

extract helper

There seems to be some "scrambling" behavior going on near the top of the function, reading and writing several lista fields. The behavior is common to both the encode() and decode() paths.

Extract that common behavior into a small helper function, which both paths call into. Consider turning the whole codebase into a class, so methods can refer to self.mumble and self.blah when accessing those carefully scrambled variables.

cryptographically strong random numbers

        senha = []
        lista[4] += str(random.randint(1, 9))

I don't know exactly what element 4 is all about. But I'm worried that on this and on other calls you wanted unpredictable numbers, and that's not what we see here. When you read the fine docs about this generator you will find that

it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes.

It goes on to explain in bold writing

Warning The pseudo-random generators of this module should not be used for security purposes. For security or cryptographic uses, see the secrets module.

versioning

You are defining your own cryptographic primitive here, something that all the textbooks advise against doing. You will make mistakes. (Ok, further mistakes in future.) You will find occasion to make Breaking Changes to the file format, as you revise the encryption algorithm.

Write a magic number at the beginning of each encrypted output. Follow it with a version number, so your code can recognize the appropriate algorithm to use with one blob of bits or another, and so you can offer backward compatibility for historic files written in previous years.